Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
Peaker
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
50 ms
·
361.
▲
by
Peaker
12y ago
At my company, I wrote our own build system, because "make", "waf", "shake" and various others do not give any useful guarantee, and we've debugged cryptic under-specified dependencies way too many times.
362.
▲
by
Peaker
13y ago
gcc has not warned about unreachable code for years[1] now :( clang -Wunreachable-code does, though. [1]: http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html
363.
▲
by
Peaker
13y ago
> The course of execution cannot be altered by the values of the input. Cache line eviction? All memory access is statically known in advance. Branch prediction? There are no branches This might be what it looks like before GHC had its w
364.
▲
by
Peaker
13y ago
You can, but: A) Legitimate libraries don't (unless the IO action is in fact pure) B) Rogue libraries that do this will not generally work: laziness, optimizations, RTS races can all make the IO action run 0..N times, arbitrarily. C) I
365.
▲
by
Peaker
13y ago
We're not talking about a malicious XML library here, though. We're talking about a misunderstanding regarding what happens during legitimate parsing of XML.
366.
▲
by
Peaker
13y ago
Or, if you use existing parsers in a language like Haskell, you know parsing is supposed to be a pure function. If parsing suddenly requires IO effects, you can be suspicious and try to figure out what is going on.
367.
▲
by
Peaker
13y ago
A security bug may well require enabling a feature, rather than disabling one, and then you end up with exactly the same problem. I personally detest #ifdef's, and would rather have multiple .c files that I can choose from to include
368.
▲
by
Peaker
13y ago
Many projects that care about performance and memory fragmentation use per-purpose free lists, and not malloc/free. The performance is significantly better, and there is a much smaller danger of running out of space due to fragmentatio
369.
▲
by
Peaker
13y ago
Unless you're willing to move the burden to the programmer, to prove correctness. Bugs can always be found statically, but there may always be bugs that evade all the static analysis you happened to do.
370.
▲
by
Peaker
13y ago
It would help, but it wouldn't get rid of the errors. It would convert corruption/security bugs into other, much safer runtime errors. To get rid of the runtime error altogether, we need a stronger type system or a different form
371.
▲
by
Peaker
13y ago
In my experience, performance is dominated almost completely by memory throughput and/or memory latency (depending on whether the prefetcher succeeds). All the instruction latencies, VLIW optimizations, and so forth have a minor effect
372.
▲
by
Peaker
13y ago
OTOH, bugs in auto-generated code are much less common.
373.
▲
by
Peaker
13y ago
I've never heard anyone describe function pointers as meta-programming before. Functions are data, just like other kinds of data. I use them in C whenever what I want to parameterize is behavior, and not, say, an integer or a string. I
374.
▲
by
Peaker
13y ago
For some value of "worked", in which people generally have to "make clean" every now and then, have false negatives that cause crpytic bugs now and then. Not to mention auto-generated code being extremely difficult to wo
375.
▲
by
Peaker
13y ago
The reason my friends use it rather than Google hangouts, as an example, is the unique combination of features: * Works on all phones * Has persistent chat groups
376.
▲
by
Peaker
13y ago
The problem is that make and all make-based systems that do anything non-trivial (e.g: code generation) are terrible. They all do dependency graph computation prior to starting building, which in the case of code generation + dependency sca
377.
▲
by
Peaker
13y ago
Even if you allow tail recursions, you still may want to disallow general recursions.
378.
▲
by
Peaker
13y ago
I do a lot of Haskell development, but virtually nil web development. I know the Yesod ecosystem is well-developed and should have good solutions for most problems. I think the downside of Yesod is that it is not as principled/based-o
379.
▲
by
Peaker
13y ago
It's (toJson foo) on the entire data, however complex, as long as there is a sane way to jsonify it. For example, if the data contains functions, there's no default way to convert it into json. And also, deserialization is going t
380.
▲
by
Peaker
13y ago
In Haskell, I can add a single line containing a macro to derive the JSON [de]serialization code. Even when there's no simple 1-to-1 mappings. I don't see why you think unityping makes this serialization easier?
381.
▲
by
Peaker
13y ago
The request was for some examples of the claim. You just repeated the claim.
382.
▲
by
Peaker
13y ago
Why? __repr__ (or __str__) is pretty much the "show" method, in Python. It isn't derivable (or rather, the default derivable one is useless), though.
383.
▲
by
Peaker
13y ago
The feature exists in emacs and vim, and is nice but not mandatory. It should be easy to integrate into any editor.
384.
▲
by
Peaker
13y ago
My experience with Python had been that scaling to large code bases is possible, but the burden of the late runtime errors and lack of type documentation accumulates. The beginning of the project is wonderfully productive. By the time you r
385.
▲
by
Peaker
13y ago
At least in Haskell, which encourages writing pure functions, testing is easier. Also, QuickCheck can use static types to make tests more concise and cover more ground more quickly.
386.
▲
by
Peaker
13y ago
Fortunately, your IDE can use inference to add a type signature with a keystroke.
387.
▲
by
Peaker
13y ago
In Python, you have to reimplement __repr__ for every class whereas in Haskell you use deriving Show. This has nothing to do with static vs dynamic.
388.
▲
by
Peaker
13y ago
I'd support fines that are proportional to general revenue or profit. A fine must hurt. Also, an audit and 300% fines would probably not kill companies.
389.
▲
by
Peaker
13y ago
You're compiling for x86, not AMD. The crippled AMD version is based on a runtime check.
390.
▲
by
Peaker
13y ago
I had no idea :-) they seem to work well enough...
More ›