• 0 Posts
  • 36 Comments
Joined 2 years ago
cake
Cake day: August 3rd, 2023

help-circle
  • The basic problem is that identifiers can be either types or variables, and without a keyword letting you know what kind of statement you’re dealing with, there’s no way of knowing without a complete identifier table. For example, what does this mean:

    foo * bar;
    

    If foo is a type, that is a pointer declaration. But if it’s a variable, that’s a multiplication expression. Here’s another simple one:

    foo(bar);
    

    Depending on how foo is defined, that could be a function call or a declaration of a variable bar of type foo, with some meaningless parentheses thrown in.

    When you mix things together it gets even more crazy. Check this example from this article:

    foo(*bar)();
    
    

    Is bar a pointer to a function returning foo, or is foo a function that takes a bar and returns a function pointer?

    let and fn keywords solve a lot of these ambiguity problems because they let the parser know what kind of statement it’s looking at, so it can know whether identifiers in certain positions refer to types or variables. That makes parsing easier to write and helps give nicer error messages.












  • Another big factor is that every plant is effectively a completely custom design. Because of how few nuclear plants are constructed, every new one tends to incorporate technological advancements to enhance safety or efficiency. The design also has to be adapted to the local climate and land layout. This makes every single plant effectively one of a kind.

    It also tends to be built by different contractors, involving different vendors and electric utilities every time. Other countries have done better here (e.g. China and France) mostly due to comprehensive government planning: plopping down lots of reactors of the same design, done by the same engineers. Although these countries are not fully escaping cost increases either.

    You are completely correct that regulation is also a big factor. Quality assurance and documentation requirements are enormously onerous. This article does a pretty decent job explaining the difficulties.



  • I think holding more helium in a smaller space is the opposite of what you want. The lifting force is equal to the weight of the air being displaced, so you want as little stuff as possible in as big a volume as possible.

    Maybe if you went the other way round and compressed the atmosphere?


  • A system I work with gives all keys a string value of “Not_set” when the key is intended to be unset. The team decided to put this in because of a connection with a different, legacy system, whose developers (somehow) could not distinguish between a key being missing or being present but with a null value. So now every team that integrates with this system has to deal with these unset values.

    Of course, it’s up to individual developers to never forget to set a key to “Not_Set”. Also, they forgot to standardise capitalisation and such so there are all sorts of variations “NOT_SET”, “Not_set”, “NotSet”, etc. floating around the API responses. Also null is still a possible value you need to handle as well, though what it means is context dependent (usually it means someone fucked up).





  • Can you elaborate where your confusion lies? It’s a digital good, there is no marginal cost. So they can pretty much price a game however they want. So pricing is mostly about maximising revenue, i.e. get as many sales as you can at the highest possible price.

    A sale is a relatively straightforward strategy where you first sell the game at a high price to all the people who are fine with paying a lot, then you lower the price to sell more copies to the people who weren’t willing to pay the higher price. The result is more total profit. There is a time limit too to create a sense of urgency (“I better buy now so I don’t miss the opportunity”).