Peaker

24 ms·

151.
by Peaker 11y ago
Why is only destructive useful?
152.
by Peaker 11y ago
> We do not know a whole lot about code just because it has type checked. It may feel like you do, but that's just a feeling. You can know a whole lot because it type-checked. What exactly you know depends on how you leveraged the t
153.
by Peaker 11y ago
This nice property is not part of 'parametricity' as I know it, though.
154.
by Peaker 11y ago
I agree with everything you said :) I also think Lisp is not truly "better" in the sense "worse-is-better" is ascribing. But if we suspend disbelief - then the Go vs. Rust story matches the one described in "Worse i
155.
by Peaker 11y ago
Go is a simple language, with 1970's features. It is very easy to implement, and leaves a lot of the complexity (null pointers, generics, etc) to the user instead of solving it in the language. This is a classic example of worse-is-bet
156.
by Peaker 11y ago
How do GADTs or type families weaken parametricity?
157.
by Peaker 11y ago
Isn't charging small watches a negligible amount of energy?
158.
by Peaker 11y ago
Without purity, you have the power to express a lot more, burdening the reader. Purity lets you easily and arbitrarily constrain a function or program -- easing the burden for the reader who is free to assume so much more about what they re
159.
by Peaker 11y ago
Note that Haskell extensions all compile (straight-forwardly) down to a relatively bare (typed) language. That is, the set of fundamental concepts exposed is no greater than the bare language, except the higher abstraction allows controllin
160.
by Peaker 11y ago
Haskell does support an imperative style, supports it quite well even :)
161.
by Peaker 11y ago
People will be under far smaller pressure to work at all costs. They will search for a job much longer. They will sacrifice their pay and benefits far less. Thus, their overall wage will be much higher (though it may be subsidized by basic
162.
by Peaker 11y ago
It may mean some products will cost more, because there is no one to exploit to build them for cheap. And that's a good thing.
163.
by Peaker 11y ago
But only the single largest serial number, and the number of samples are being used. Not any of the serial numbers seen besides the largest one. That means any such noise as you describe will have no effect. As long as a high-serial number
164.
by Peaker 11y ago
If someone doing a PhD on some subject made it PhD level and inaccessible to non PhDs, you wouldn't be able to use virtually any of the data structures you use today. Additionally, even if discovery of a certain pure algorithm is diffi
165.
by Peaker 11y ago
Indeed I believe in Python's motto of "Errors should never pass silently. Unless explicitly silenced." I think that Javascript's silencing of wrong parameter counts, Perl's (non-strict) allowing string concat, and n
166.
by Peaker 11y ago
I see this behavior as implicit error silencing. Wouldn't you prefer seeing: foo .? bar . baz .? roo To know that nil is not even a possibility for `bar`? Why not make the nil check (or error silencing) explicit when it is so ch
167.
by Peaker 11y ago
If the entity you are communicating with is out to subvert the encryption you are using with them , couldn't they just plain-text transmit everything in your communication to other channels? What you are saying seems to only make sens
168.
by Peaker 11y ago
They also decrease the incentive for people to do research and development (e.g: as derivative works from existing inventions). Which effect is stronger? It is very plausible that overall, the decrease is far stronger than the increase, as
169.
by Peaker 11y ago
`Promise a -> (a -> Promise b) -> Promise b` is missing some parenthesis.
170.
by Peaker 11y ago
The point of the essay is that the incompetence causes reasonable doubt not to mean much. And that's why they end up executing innocent people.
171.
by Peaker 11y ago
Do you intentionally leave out parens in the #define for MODULE_SIZE? If it was used in a context with higher precedence than multiplication, it'd be a bug.
172.
by Peaker 11y ago
The memory hit is an interesting point, could be useful if there's a static validation on worst case stack size. The smaller allocation is worse as it hides potential bugs.
173.
by Peaker 11y ago
What's the benefit over just allocating the worst case size? If worst case size is too large, your program is broken anyway on some of your inputs.
174.
by Peaker 11y ago
VLAs are just a bad idea. A. They make stack allocation much more dynamic, harder to reason about its bounds, and arbitrary inputs may blow the stack later. B. They make sizeof a dynamic thing! sizeof can no longer always be constant folded
175.
by Peaker 11y ago
If you want them on the stack, it's safer to use MAX_SIZE so that you don't blow the stack when some arbitrary input arrives in the future.
176.
by Peaker 11y ago
You're forced to declare them before they have a sensible value to use. You're exposing your code to unnecessary bugs where you user the variable prematurely. Variables tend to be declared further from their use, making it harder
177.
by Peaker 11y ago
What would be considered abuse here? Beginning of block variables are generally always worse than as late as possible variables.
178.
by Peaker 11y ago
Java lacks higher-kinded parametric polymorphism. Java also lacks the ability to say something like: class Foo<T> implements ISerializable iff T implements ISerializable So you end up having to work only with T's that are
179.
by Peaker 11y ago
It can grow cartesian though. I think the best compromise is to declare a new data type for the argument, such as: data ExecutionDirectory = ExecuteInCWD | ExecuteInDir FilePath And take an ExecutionDirectory instead of a `Maybe File
180.
by Peaker 11y ago
When some ELisp code crashes in my emacs with an error like: error: (stringp nil): not a string I think it indicates Lisps suffer from this problem too...

More ›