Disqus - Latest Comments for Norswap

Re: The new EVE survival MMO is using blockchain tech to create a 'boiling financial hellscape,' but don't call it a blockchain game

Norswap — Fri, 13 Sep 2024 17:42:38 -0000

Most blockchains are not more environmentally harmful than your Google/Amazon/Meta datacenters.

It's only "proof of work" blockchains like Bitcoin that consume a ton of electricity.

This will not run on one such blockchain (Bitcoin is not capable of it can only program very basic money-like things).

Re: A `ps`/`pkill`/`pgrep` alternative.

Norswap — Fri, 15 Mar 2024 01:40:40 -0000

Nice trick!

Re: Optimism Bedrock vs Arbitrum Nitro

Norswap — Tue, 10 Oct 2023 09:37:47 -0000

Might be! I guess it comes down to whether it's possible to compiler Go concurrency deterministically to MIPS in practice, which is what is needed here.

Re: Optimism Bedrock vs Arbitrum Nitro

Norswap — Tue, 08 Nov 2022 18:37:07 -0000

Arbitrum has a fault proof systemI think the code should be mostly here? https://github.com/Offchain.... It can only be triggered by Arbitrum themselves, however you can definitely investigate the code!

Optimism has Cannon (github.com/ethereum-optimis.... It's not deployed, and under development at the moment. It will be one of our top priorities after the Bedrock release. That being said, the current code and documentation (check the wiki) should also prove instructive.

Re: Running Myself Ragged

Norswap — Tue, 12 Oct 2021 16:58:41 -0000

I think so. I ended up not having so much of a break (though the worse was past when I wrote this) and then as my course was barely ending and the exams not yet correct I got signed up in the Ethereum apprenticeship :)

The apprenticeship ended up being pretty intense too (owing in a large part to me wanting to catch up on ALL aspects of crypto), and so I'd like to think that this previous intense experience helped. However, a big difference was my motivation level was higher overall. One unstated part of the article is that I was super unmotivated by my day job on top of the rest :)

Re: Freaking blockchains: How do they work?

Norswap — Thu, 27 May 2021 20:07:48 -0000

So it would seem! Even though it sounds less good to me :')
I'll leave it as-is, gotta keep a little bit of that foreign flair!

Re: Truffle Tutorial: Adding 1 and 1 Together

Norswap — Wed, 09 Sep 2020 13:42:37 -0000

Haha trust me, I don't judge, that's the kind of dumb stuff I do myself all the time :)
Glad to see you could solve the issue! Let me know if you have any other issues!

Re: Prolog Served DRY

Norswap — Fri, 16 Aug 2019 19:11:40 -0000

Interesting! I think once you get the main gist of Prolog, this is actually just boilerplate. Nevertheless, the pedagogic value of explaining Prolog clauses as nested for loops with yield is really interesting! (Though I do not expect most of my student actually know yield/continuations, unfortunately.)

Re: C: Scope, Duration & Linkage

Norswap — Wed, 03 Jul 2019 17:21:19 -0000

You're right! But this is cover in the text, though it's not immediately obvious:

For all other objects in the compilation units, the object has internal linkage
if there is a declaration with the static storage class specifier. This
declaration must happen before any extern declaration, and there cannot be any
declaration without storage class specifier (or a compilation error ensues).
Otherwise, it has external linkage.

If you read the above carefully, it says that if there is a declaration with the static specifier, then the object has internal linkage.

This is a bit confusing, because before I talked about the linkage of declarations. But when you think about it, all the declarations for an object must have the same linkage: it's not possible for an extern declaration to refer to an object that has a static declaration in another compilation unit.

So what it really means is that both declaration have external linkage. I make this clearer when i say in the summary at the end that `extern` "copies" the previous linkage.

Maybe the confusion stems from thinking that static = internal linkage, and extern = external linkage. Alas, things are not as simple as that!

Re: Overconfidence From Moral Signaling

Norswap — Thu, 13 Dec 2018 10:08:54 -0000

I'm not sure what he meant! But if he meant what I said, then yes, you are right and the question is confusing or even not phrased correctly.

That being said, what I proposed isn't meaningless as a question!

Your second paragraph, speaking of my interpretation, is entirely correct. The fact that the event is historically significant and emotionally laden does not chance the fact that maybe outcomes are still possible.

In fact, if I read Robin's post correctly, *I think* that's his point: even if something awful happened in the past, there is a non-trivial chance that things might still have turned as well or better than they actually have. That's interesting and unintuitive!

Re: Overconfidence From Moral Signaling

Norswap — Thu, 13 Dec 2018 09:19:16 -0000

You're missing the point. You're thinking direct cause and effect, rather than random butterfly effects.

There isn't ONE timeline that starts at a south victory, but many. It's obvious that some of these timelines would end up better than our current situation (those were humanity gets lucky each time afterwards, after getting unlucky on the south winning). The question is, what proportion of these "random timelines" end up better than the one we are currently on.

And you completely ignored the part when I said maybe we should only consider the situation that this timeline leads to in 2018 (so we ignore any suffering in the process to getting there).

Re: Overconfidence From Moral Signaling

Norswap — Thu, 13 Dec 2018 08:47:46 -0000

I had the same interrogation. I don't think Robin's point is about particular scenarios: each scenario being unlikely, only the aggregates matter.

History could have gone in many different branches, even in north wins / allies win case. Some of these branches are of course better than current. The question is: are there 10% of branches in the south wins / nazi wins case that are better than the current branch?

Nevertheless... slavery and holocaust are huge downsides. One chance in ten to have outcomes that are so much better than the current situation that the outweigh those... That's a TOUGH proposition. I can only see it as possible if you argue that since many more people are alive today than were before, increased well-being of people alive today outweighs the suffering of people in the past; or that only the "snapshot" situation matters, with past suffering not considered at all.

Rephrasing once more using this charitable interpretation: are there 10% of scenarios in the south wins / nazi wins case where the downsides disappear and we (the alive people) are better off today? (Maybe - probably? - coincidentally with the fact that south/nazis won.)

@RobinHanson Could you enlighten us on how you conceive of the question?

Re: Men Are Animals

Norswap — Sat, 09 Jun 2018 08:08:28 -0000

The exploration hypothesis definitely makes a lot of sense in the course of human history.

This hypothesis is explored in the classical write-up "Is Anything Good About Men?" by prof Roy Baumeister: http://www.denisdutton.com/...

Re: Ruby Module Linearization

Norswap — Thu, 30 Nov 2017 15:23:02 -0000

Interesting... the example doesn't match at all with the rules I've laid out.

It could be true up to a difference in ordering, but then the description on wikipedia is obviously incorrect:

"The merge of parents' linearizations and parents list is done by
selecting the first head of the lists which does not appear in the tail
(all elements of a list except the first) of any of the lists. Note,
that a good head may appear as the first element in multiple lists at
the same time, but it is forbidden to appear anywhere else. The selected
element is removed from all the lists where it appears as a head and
appended to the output list. The process of selecting and removing a
good head to extend the output list is repeated until all remaining
lists are exhausted. If at some point no good head can be selected,
because the heads of all remaining lists appear in any one tail of the
lists, then the merge is impossible to compute due to cyclic
dependencies in the inheritance hierarchy and no linearization of the
original class exists."

There could be no good head without there being a cycle in the inheritance hierarchy, that is the case of scenario 5 in my article.

Re: Imperative Ambiguity

Norswap — Mon, 27 Nov 2017 06:30:42 -0000

Ha, I did know about Chekers, but not the Linear annotation. Interesting!
Can JML really solve these ambiguities? Can find something that would fit the bill here: http://www.openjml.org/docu...

Nevertheless, I think there is something to be said for a new language. The problem is you really want to have these guarantees as a library user, meaning the library user has to annotate his program. Little chance he will do so if he's not forced too or the tool is not super popular. Typescript (which is a "new language" anyway) runs into this problem when using vanilla JS libs. However, they kind of ease things by enabling users to add externally maintained annotations to an existing library.

Re: Java Reflection, 1000x Faster

Norswap — Thu, 14 Sep 2017 05:04:18 -0000

Yes going from http://wiki.jvmlangsummit.c..., that seems to be it.

Although, thinking about it, I'm not sure it optimizes the reflection away as soon as it generates the classes, but since these are their own classes, the JIT can easily do so later.

Re: Java Reflection, 1000x Faster

Norswap — Thu, 14 Sep 2017 04:27:24 -0000

I don't think it performs a specific optimization itself, more like it applies standard optimizations that wouldn't otherwise been applied. And clearly the JIT is more than capable of optimizing reflective access away in certain occasions.

I think that's the trick of the metafactory: using it "summons the compiler" each time and so we get an optimized version each time (because the type of the class is known, so there isn't actually any polymorphism for a single factory call).

Regarding getters: yes it's because my original example was in Kotlin which has auto-generated getters. Nice catch! Although it seems like a huge proportion of people just always throw in the getters no matter what...

Ultimately an annotation processor is just integrated code generation, which is indeed a nice solution -- it was going to be my permanent solution (well code generation in some form at least), but then this seems to be fast enough to not be worth it.

Re: Java Reflection, 1000x Faster

Norswap — Thu, 14 Sep 2017 04:20:17 -0000

The link says that invokedynamic is only used at the time where the lambda is created (~LambdaMetafactory call), so I don't think it can account for the difference in performance, since that should be related to invoking the generated lambdas (well, NodeGetter in our example). It's probably that the generation causes optimizations that are not otherwise triggered.

Re: Principles of Automated Testing

Norswap — Tue, 18 Jul 2017 05:22:21 -0000

Ah okay, when I hear automatic I think not having to pick test cases explicitly.

And I don't know, I have a feeling that many subtle bugs involve some rare combination of events that you wouldn't think of testing. It's combinatorics: the more parts you have, the more combinations exist. And those don't have to be high-level components, even just the different operations on a simple data structure already give rise to a huge number of scenarios.

It's definitely not a silver bullet in the sense that the approach is clearly not practical for some cases. Besides the difficulty of generation itself, what is often problematic is automatically verifying that running the code on the input does what is expected (i.e. providing redundancy) -- sometimes there isn't aren't two different enough ways to do something, or implementing the second way would take too much time.

Re: Principles of Automated Testing

Norswap — Sun, 16 Jul 2017 19:12:29 -0000

Great article!

Most of the discussion seems to be about "just testing", i.e. I'm missing the "automated" part a bit (you do however talk of fuzzing, and of testing your parser against large amount of data).

What are your thoughts on random input generation, as described here: http://norswap.com/gen-test... ?

Re: Metaprogramming is less fun in D

Norswap — Fri, 21 Apr 2017 14:52:11 -0000

So, why is it "less fun" exactly?

Re: Latex Tooling Guide

Norswap — Fri, 31 Mar 2017 07:29:33 -0000

I think the strong suit LyX is indeed starting a document "from scratch" rather than sharing with an existing TeX codebase, or importing templates.

Re: Latex Tooling Guide

Norswap — Fri, 31 Mar 2017 07:28:37 -0000

All my experiences with LyX have ended in frustration. I just took it for a spin, and I cannot even manage to import my tex file. It gives an unhelpful error. Would I manage that, I seem to recall from past experiences that LyX isn't really hot at handling custom styles (that are required for conference submission).

Re: Latex Tooling Guide

Norswap — Thu, 30 Mar 2017 08:25:20 -0000

When you say errors I suppose you mean "bugs"? Then I'd say TeX has no bugs. Maybe the core set of LaTeX macros (I don't really know what belongs in there). LaTeX packages, in general, have plenty of breakage.

I don't want to advocate buggy software, but I'd take a buggy system (where the bugs can be worked around) which imposes less pain over Latex any day.

TeX may work according to spec, but the spec is triple meh.

Re: Latex Tooling Guide

Norswap — Wed, 29 Mar 2017 20:56:38 -0000

Hacker News Discussion: https://news.ycombinator.co...