Peaker

14 ms·

91.
by Peaker 10y ago
But then you lose C's nice property that declaration and use are the same syntax. For example, D also uses a similar type syntax, so in D if you declare: int[10][20] x; x[19][9] // is legal In C: int x[10][20];
92.
by Peaker 10y ago
I didn't say Israel is objective. But the parent post is taking a true point and hyperboling it into a total lie. Israel is bad enough without the lies trying to make it seem even worse -- discrediting its detractors.
93.
by Peaker 10y ago
Shaked (an Israeli minister) posted (and thus endorsed) a text that calls for genocide. While many Israeli politicians are terrible, I don't think that single endorsement substantiates your claim that "many Israeli politicans have
94.
by Peaker 10y ago
Haskell programmers do have to think about it as being by-reference if they want to understand the performance/memory-use due to sharing. But for correctness, yeah, you just don't have to think about it. So you don't think &q
95.
by Peaker 10y ago
Haskell doesn't necessarily capture by value or by reference since you cannot distinguish between the two when all values are immutable.
96.
by Peaker 10y ago
I don't think git won over bzr just because of speed. It was also much more powerful in meaningful ways (`git reset <hash>`, `git rebase -i`, ...) very early on. Also, the internal git model is elegant. Having used bzr for years,
97.
by Peaker 10y ago
Are you referring to darcs? Git is quite elegant underneath the terrible UI.
98.
by Peaker 10y ago
On Intel CPUs there's virtually no cost for misaligned access. Of course, if your misalignment results in your data spanning 2 cache lines instead of 1, that'll be costly, but that's regardless of alignment.
99.
by Peaker 10y ago
It seems to be equivalent to Haskell's Void type. The Void type is simply the type of no values. If you cannot create a value of this type, yet you "return" it, then it is proof that you never return.
100.
by Peaker 10y ago
It's true until the composition and data flow are hidden from view because they're implicit in the shared mutable state. Also aliasing issues don't occur with the composition as they may occur in mutable state.
101.
by Peaker 10y ago
It does, but unlike impure languages, this ordering is not implicit in the evaluation order -- but explicit. In the same sense, if you compose the pure functions: updatePacmanPosition . checkPacmanAlive vs: checkPacmanAlive . up
102.
by Peaker 10y ago
You cannot implicitly read pacman.position as a subexpression like in C, because it is an effect, and the order of effects has to be explicit in Haskell. So it would have to look like: pacman.position += speed pos <- pacman.positio
103.
by Peaker 10y ago
It seems at least some of the difficulties described are managed better in Haskell. For example, rebinding to the same name (as an alternative to destructive update) can be handled conveniently and nicely via state monad and the lens librar
104.
by Peaker 10y ago
> But for simple games these are not that useful. Simple games seem very well suited for the imperative, global state model. I think this indicates a bias -- resulting from years of programming games in these models. I think pure FP in t
105.
by Peaker 10y ago
While RAII and exceptions are better than goto's, the "goto fail" bug is not an example of that. The problem there was mismatch between indentation and parse which was a result of brace-less style and whitespace-insensitivity
106.
by Peaker 10y ago
Many icons are well known and work well. The back, forward, reload buttons are more usable as icons than text. When not overused, operators are similarly more usable than verbose English names.
107.
by Peaker 10y ago
It increases the regularity of the syntax (infix is not special) - and reduces $ noise which does not aid readability. I have been using Haskell for around a decade and hate every infix operator spam I have to throw in there to please this
108.
by Peaker 10y ago
I can try to explain why HM type inference and unification are related. If you take just the lambda calculus where you have: 1) Lambdas that bind variables 2) Usages of bound variables 3) Function applications The inference rules for the fi
109.
by Peaker 10y ago
Another really helpful resource to understand algorithm W inferring types for HM is Algorithm-W-Step-by-Step at [1]. [1]. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65....
110.
by Peaker 10y ago
Great comment. I disagree about manual memory management though, you don't have to traverse the heap, unless you use a semiautomatic scheme like reference counts. Complex heap structures often aren't a problem for manual memory ma
111.
by Peaker 10y ago
Non-determinism comes in many forms. I don't think it's an all or nothing thing. Eliminating non-determinism is always nice, even if lots of other non-determinism remains. Having predictable and understandable resource use is a ni
112.
by Peaker 10y ago
I think in ~10 years of C development, I had seen maybe 1 corruption bug slip through the testing suites to production. The vast majority are caught in unit tests, system tests, or QA. I think it took 2-3 days of a 2-3 devs, but that's
113.
by Peaker 10y ago
Hundreds of thousands of LOCs. ~15 developers I didn't say there were no corruption issues. Just that they're rare and a very small minority of the time is spent chasing them. In return, get determinism and optimality of execution
114.
by Peaker 10y ago
> Clojure has STM and isn't pure at all. Not guaranteed STM. If you do IO in Clojure's STM, you just get a runtime error (assuming the IO does not forget to use the runtime-check that it isn't executing in STM context).
115.
by Peaker 10y ago
There are a lot of tangible benefits over, say, OCaml. Let me use one particular representative one: STM. Haskell can successfully implement a performant STM with static guarantees regarding transactions. How would you add practical, guara
116.
by Peaker 10y ago
> PFP and typing are quite orthogonal They are orthogonal in 1 technical sense. But the benefits are reaped from the combination. > the PFP abstraction has so far failed to yield results commensurate with its cost. You say this based
117.
by Peaker 10y ago
If you call 'next' on an IO stream, you always get the same answer, an IO effect which, when executed, would destructively get the next item: next :: Stream a -> IO a The function part is pure. The `execution` of the res
118.
by Peaker 10y ago
Having done a lot of C code without dynamic memory allocations at all -- chasing memory corruption was a thing, but a rare thing. I spent more time chasing performance issues and tuning GC in some projects than I did chasing memory corrupt
119.
by Peaker 10y ago
I enjoy both kinds of languages. I do think garbage collectors are overrated. When using certain styles in C or C++, memory management is really a tiny aspect you have to spend a tiny minority of your time thinking about -- but you gain so
120.
by Peaker 10y ago
I disagree. Haskell, like Perl, gives users more freedom to express themselves than other languages. Unlike Perl, many (most?) Haskell features are oriented towards ease of statically understanding programs without executing them. Haskell c

More ›