HN user

joejev

262 karma
Posts9
Comments68
View on HN

Isn't the entire point of an optimizer to convert "bad code" into "good code"?

Your proposed solution is to have the user manually implement a hash table, but if you have a good optimizer, users can focus on writing clear code without bugs or logic errors and let the machine turn that into efficient code.

Interesting idea, but this implementation has UB:

    typedef void* var;

    struct Header {
      var type;
    };

    // ...

    #define alloc_stack(T) header_init( \
      (char[sizeof(struct Header) + sizeof(struct T)]){0}, T)

    var header_init(var head, var type) {
      struct Header* self = head;
      self->type = type;
      return ((char*)self) + sizeof(struct Header);
    }
The section "struct Header* self = head" is UB. The alignement requirement of the local char array is 1 but the alignment requirement of struct Header is that of void* which is probably 8.

It's not an ad-hoc turing complete language, it is just a programming language. Makefiles are just programs. There are some strange implicits, but that isn't unique to the Make programming language.

The argument comes down to when the undefined behavior occurs: is it at the deference to create the reference, or is it on the first memory access using the reference? The language pedants will say the former, but in practice, it's the latter.

The undefined behavior is always when the null reference is created. The issue will _usually_ manifest when you try to dereference the pointer, but the undefined behavior was creating the null reference in the first place.

And regardless of that, if my employer is willing to pay our CEO over 20x what they pay their average employee, they are not in a position to niggle over the kinds of systemic inefficiencies they would suffer under a union.

Do you not believe that a CEO could have at least 20 times the impact on the value of a company than the average employee, and if so, should they not be compensated accordingly?

Great write up. I am a maintainer of a project you opened a PR on, but the diff is large and seems to include unrelated changes. Maybe you based of a fork and the opened the PR to upstream? If the bot had worked as intended I would have thought it was cool, but given that it opened a large PR with an incorrect description I found it harmful. I guess the problem with these bots is that it is easy for you to make a mistake which takes a lot longer for people to deal with than it took for you to make, so github needs to ban these to prevent this.

Many games (by common definition) are strictly execution based. For example, most rhythm games (e.g. Osu!, Beatmania, DDR, Guitar Hero, etc) do not have any element of randomness or strategic requirements, yet some people find them very fun.

I can see the art being preserved as a critical feature for adventure games, but with StarCraft remastered it seems everyone loves the new art. The most important thing for that game was to keep the gameplay exactly the same while supporting newer displays.

For too long, Blizzard was far too afraid to make sweeping changes to their game in the same vein as DotA or League.

Why are big changes a good thing? As someone who started playing brood war since the remastered release, I really like that the game is the same as it ever was. Leave tweaks to the community through map making. People come up with all kinds of fun ways to change up the game like reverse ramp mains or that weird assimilator/neutral egg setup on gold rush.

When I was still playing SC2 I appreciated how well thought out the changes were, for example when they increased the range of queens. That had such a huge affect on the game but it all came from such a small change.

Interesting article, including the subtitle, "Their case against frugality", may help people understand what the article will be about. The article title alone is quite vague.

More syntax makes a language harder to read. The point isn't that making this special syntax would be harder, because it's not that hard. The point is that you don't need new syntax. In this case, the new syntax saves a few characters at best. I'm also don't think this syntax is any easier to read than a function call; I actually think it looks so similar that it would be easy to confuse with a function call making the language harder to read.

Why is (x=1, y=2) more practical than nt(x=1, y=2)? Also, we have a very efficient implementation for tuples. collections.namedtuple is quite fast and the article shows cnamedtuple (which I am the author of) which is a C implementation that is even faster. None of this needs a change to the language itself.

The reason the syntax was rejected is that you can implement the exact same feature without special syntax. You could write: nt(a=1, b=2) and dynamically create a struct to store the data. In 3.6 this even preserves the order of the keyword arguments.

One advantage of namedtuple is that it is just a tuple! You can pass the namedtuple to code that expects a tuple, even C code that expects a tuple. This makes it easy to add names to tuples after the fact without breaking existing code.

In one project, I use a Point2D class as a namedtuple. Because it is just a tuple, I can easy convert it to a numpy array when working with a collection of points.