implicit

7 ms·

31.
by implicit 10y ago
I remember that. One of the crypto libraries was implemented by using unsafePerformIO to access a global handle to /dev/urandom rather than accepting another parameter. For what it's worth, this bug was an outlier. The pitf
32.
by implicit 10y ago
Something I'm working on on the side is a way to run my sandbox in a Docker container inside a Linux desktop environment without any VM at all. If I can get this working, my source code will just be a bind mount that's accessable
33.
by implicit 11y ago
Sure. I've previously written up a short description of the approach here: http://andyfriesen.com/2015/06/17/testable-io-in-haskell.htm... The general high-level approach is that your business logic fun
34.
by implicit 11y ago
I write Haskell in production. One of the things we've built is a unit testing harness that denies application-level code any access to unrestricted IO. If a proper mock is not in place, type checking fails before the tests even begi
35.
by implicit 11y ago
> Anyway, therefore it follows that if we calcify and ossify data structures and types, we kill the progress, not to mention fun. I don't think it's fun to ship bugs to customers. I think it's much more fun to have a perva
36.
by implicit 11y ago
My experience is that typed functional programming is excellent for any application that can afford to run a garbage collector and needs to to be able to change continuously forever.
37.
by implicit 11y ago
I'm at IMVU. We're hiring! :) http://www.imvu.com/jobs/index/ I intended to react to the comment "But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. The
38.
by implicit 11y ago
This matches my experience. At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to do things. We provide just one way to do things like report errors, run quer
39.
by implicit 11y ago
How is "information flow control" different from a type system? I've always considered the primary purpose of type systems to be restricting how data can flow through a program.
40.
by implicit 11y ago
Agreed. More concerning is the bit where the author says that they have "1500 coders firefighting, just keeping that legacy monster alive." I wonder if that has gotten any better since 2006.
41.
by implicit 11y ago
The problem is that developers do not know that they mustn't call datetime.now() and there will always be a developer who doesn't know this, either because people have a tough time knowing everything, or just because you're h
42.
by implicit 11y ago
You can, but in Haskell you can enlist the compiler's help to prove that everything is completely airtight. This property continues to hold, even as the application and the tests are modified by developers who do not even fully know wh
43.
by implicit 11y ago
Are you sure? > function isboxed() { return this instanceof Number; } > isboxed.call(5); true
44.
by implicit 11y ago
Right. I mean only to say that OCaml's superficial strangeness is regrettably offputting. Talk of syntax is almost always history and religion, not science.
45.
by implicit 11y ago
I don't, unfortunately, nor do I have any source code I can share. :( The only advice I can offer is that the documentation actually is correct and pretty complete, but there's nevertheless something about its organization that ma
46.
by implicit 11y ago
OCaml/js_of_ocaml is presently my favourite AltJS stack. OCaml syntax is super idiosyncratic and doesn't resemble anything, but, once you retrain your eyes, the underlying semantics are terrific. js_of_ocaml imposes very minimal c
47.
by implicit 11y ago
This is very consistently my biggest problem with OCaml: it just doesn't follow conventions set in other ecosystems. I predict this is the sole reason it could never be "the next Java." It's worth noting, however, that
48.
by implicit 11y ago
It's really valuable for mistakes to result in clear errors rather than confusing but "valid" programs. Even worse: let [a, b, c, d] = [2]; a receives 2. b, c, and d receive undefined.
49.
by implicit 11y ago
Other languages have implemented this idea for decades now. It's a great feature. The main thing that bothers me is that the default behaviour is too permissive. let a = [1,2,3,4,5]; let [b] = a; // ok. b receives
50.
by implicit 11y ago
Yesod provides a ton of functionality related to the larger problem of building a website with Haskell, but we're only using Haskell for JSON services. All those extra bells and whistles are wasted on us. :)
51.
by implicit 11y ago
They are for now, but we've been whittling away at it. We don't actually use any of Yesod's affordances except for its router. We're aiming to eventually split that off and run on bare Warp.
52.
by implicit 11y ago
> The testing frameworks out there are still fairly spartan from the developer experience standpoint. At IMVU, we built up a bit of scaffolding along these lines: https://gist.github.com/andyfriesen/43d886ce60927c69b
53.
by implicit 11y ago
I'm sure it depends on your programming style, but my experience is that you can almost always ignore laziness and focus on getting your work done.
54.
by implicit 11y ago
It's more about knowing your constraints ahead of time and working within them. If you're doing audio mixing, for instance, you probably have a thread that has to respond with samples within 1ms. Missing the window means catastr
55.
by implicit 11y ago
I worked with Chad to write BufferBuilder. We conspired our use of C++ to exclude the C++ standard library. It's basically C with stricter pointer conversion rules.
56.
by implicit 11y ago
I use this technique to achieve bulletproof unit tests in Haskell HTTP services by providing two run functions: One that runs on IO and does all the real stuff, and another that twiddles some state and produces a pure result. This nets us t
57.
by implicit 11y ago
That's a shame! "Gets the job done in just a few hundred lines of easily-explained code" is a terrific standard to meet. "Magic abstract Haskell-fu" cannot improve such a program very much.
58.
by implicit 11y ago
Hack is also a substantially better language than PHP. It, directly or indirectly, fixes a lot of horrible behaviour. PHP's absurd comparison operators, for instance, are safely usable once you drop them into a statically typed enviro
59.
by implicit 12y ago
Even as a pragma, a la "use strict"? "use stricter"?
60.
by implicit 12y ago
Is ASI really worth the amount of time that has been spent discussing it? It would be nice if it were deleted from the language entirely.

More ›