spion

77 ms·

961.
by spion 10y ago
If the monad laws don't hold, its not a monad. I demonstrated the first law not holding, therefore promises are not a monad.
962.
by spion 10y ago
Oh ok. Its not pseudocode, the combinators work :) I would put it the other way around. The http layer should not decide that the layer immediately above it must be the one to handle all its errors. It should also be the one that defines th
963.
by spion 10y ago
Well lets see if the first law holds. It says Promise.resolve(a).then(f) == f(a) Immediately this is not true, since `f` can throw or return a non-promise. But lets say we restrict the type of f so that it can only return promises. Once aga
964.
by spion 10y ago
Which pseudo code are you referring to? Exceptions being for "exceptional" circumstances is a popular misconception. Exceptions are for "an upper layer to handle". You can use them for any alternative values you wish to
965.
by spion 10y ago
If there was a specialized Observable that is guaranteed to only generate one value per subscription, and the API indicated this clearly by naming such an observable "Task" or "Future", I'd be all for it. Otherwise,
966.
by spion 10y ago
The problem wasn't usefulness or purity, it was that the community already standardised on a certain behaviour of promises that was not monadic. The only way to make promises monadic was to therefore not standardise "promises&quot
967.
by spion 10y ago
Which is why you write a catch combinator to filter out only the errors you want function ifErr(predicate, handler) { return e => { if (predicate(e)) return handler(e); throw e; } } function codeIs(n) { return e => e.code
968.
by spion 10y ago
Its already fixed. Thats why it was just "a bit" of a footgun i.e. not unfixable.
969.
by spion 10y ago
Pointless JavaScript is a bad thing. Want to take over the scrolling just because you dislike the default one? Please don't. Also, I believe that by this point the novelty of scroll animations (used to be popular a couple of years ago)
970.
by spion 10y ago
Or with an algebraic Maybe data type {this.state.user.case({ some: user => `Hello ${ user.name }` none: () => `Please log in` })} Or for async requests that are in progress, an algebraic 3-state type: https:/&#x
971.
by spion 10y ago
Without the decorator sugar, the core algorithm of MobX is also 60 LOC. The author goes through it line by line here: https://youtu.be/TfxfRkNCnmk?t=15m59s It looked "magical" and tripped up my "too good to b
972.
by spion 10y ago
I personally liked this intro: https://mobxjs.github.io/mobx/getting-started.html
973.
by spion 10y ago
Try looking for react + mobx tutorials.
974.
by spion 10y ago
The difference is that JS has no binding, yet it still allows for first class methods. Thus the OO "illusion" (object owns the methods) is broken: there are no methods, just functions that take an argument named `this`, in a sli
975.
by spion 10y ago
Here we go, a node version that uses a least-latency load balancer and doesn't exhibit the problem: https://github.com/spion/fpco-article-examples Its an interesting benchmark, but it needs more work to give a mor
976.
by spion 10y ago
I just spawned a least-latency load balancer in front of a cluster of N processes (one per core) for the benchmark. https://github.com/spion/fpco-article-examples Now it gives the same results as the Haskell solution.
977.
by spion 10y ago
Thats parallelism, and node is as bad as it gets, yes. However, it pretty good at streaming all the necessary data to another service that will do the number crunching, as well as getting the results out to the client (with light transforma
978.
by spion 10y ago
> Will you also stop accepting connections on the individual box level if you're queueing? I would not. And I agree, it will be worse than Haskell, which will only choke if the cpu intensive processes are all calculating things with
979.
by spion 10y ago
> A methodology that doesn't scale well across boxes, so only buys you so much. Demo code might benefit from this approach, but production code will do something totally different to give an API or server actual durability and uptim
980.
by spion 10y ago
> I disagree. Totally and utterly. API servers are webservers, and in fact a pretty big subgroup of them. API servers can often run into computational requirements in mid request, and it sucks that ONE slow request can cause latency ripp
981.
by spion 10y ago
First of all, there is no enormous complication. Clustering in node is super-easy, and file descriptors of requests are sent automatically to one of the processes in the process pool. This benchmark should have at least done that. Secondly,
982.
by spion 10y ago
For starvation there is also clustering, which can shift the load towards worker processes that aren't busy with cpu-intensive tasks, as well as simple modules such as ` https://www.npmjs.com/package/process-pool`
983.
by spion 10y ago
Haskell and Scala are safer than TypeScript... but not by too much :) The only major safety feature lacking in TypeScript are variance annotations and proper variance for functions, which are bivariant WRT their arguments. Short demonstrati
984.
by spion 10y ago
TS->JS is very different from both in that the resulting JS code is the same as the typescript code with the types removed. In contrast Haskell and Scala compile to entirely different (and mostly unreadable) code
985.
by spion 10y ago
JavaScript is pretty much average for a dynamic language. Also, it doesn't matter how many people think its awful. What matters are the facts they present.
986.
by spion 10y ago
"explicit" is in the eye of the beholder. Passing a this argument to any function even if its not attached to the object seems more explicit to me.
987.
by spion 10y ago
Its just not taught correctly. `this` is the hidden function argument passed by putting it left of the dot; from that, everything else follows.
988.
by spion 10y ago
By type checking I mean something like typescript which is able to statically verify whether the right types of attributes are passed to the right component, or whether expressions embedded in the template are of the right type. Re encapsul
989.
by spion 10y ago
I believe most of the brokenness of current day frameworks comes from templates. Here is what you get by JSX being JavaScript: 1. Easy to write typechecking for the templates. The compiled template is just function calls (or well, factory f
990.
Mercury Colonization(einstein-schrodinger.com)
4 points by spion 10y ago|0 comments

More ›