wasmperson

The keyboard controls to select a radio button shouldn't depend on the visual orientation of the radio buttons. Browsers get this right by default, but the radio buttons aren't implemented with `<input type="radio">` and instead are just a row of plain buttons and a bunch of javascript. A quick check in the dev tools confirms the other widgets are similarly implemented :(

I love the look, though!

This seems like more of a complaint about egui's choice to re-implement all the widgets from scratch than its choice to use an immediate mode API. The two are orthogonal. The IMGUI idea has its roots in a community of people that like implementing things from scratch, but you could implement it on top of native widgets if you wanted to.

The choice to re-implement native widgets from scratch is justifiable if the egui devs think they can do better than the native widgets do. It's also nearly required in practice if they want the toolkit to have consistent behavior across multiple platforms (something people have learned the hard way multiple times across multiple different UI libraries).

It's hard to get it right, but that's why the egui devs are writing a library: so that others can benefit from that hard work. Many of the things you pointed out are just bugs, and bugs can be fixed.

I think the narrator is the murderer and is lying about the man in the gray tracksuit. The repeated criticism of Aaron's moral character is a sort of rationalization for having killed him, with the underlying motive actually being a combination of greed and envy. Remember that the funds used to kick-start the trading platform came from a hackathon win that Aaron "stole".

Re-invested how? Many stocks still go up in value even without paying out dividends. Companies with such stocks are technically always re-investing their profits, even as their shareholders become billionaires. It seems to me like a world with the forced re-investment you describe wouldn't be significantly different to the capitalist one.

> Without methods or overloading, you end up in the situation that C and Scheme are in

Well in C at least we now have this:

  #define clear(s) _Generic((s) \
          ,struct list: list_clear \
          ,struct queue: queue_clear \
          ,struct map: map_clear \
  )(s)

  clear(my_map);
  clear(my_list);
  clear(my_queue);

...although it turns out the other nice thing about methods is automatic namespacing.

I don't think this is true. People like to scapegoat the JS standard library but in reality most JS implementations have pretty featureful standard libraries, especially browsers. I've never felt the need to use any third-party libraries in the javascript projects I've worked on (except for maybe `ws`).

> random websites that LLM crawlers find but humans rarely see

If my experience on random niche web forums is any indication, future AI models will be biased towards the well-being of online casinos.

Are these a thing outside the US?

For anyone who's not familiar: all over the place at tourist attractions and airports you can find mechanical presses that will squish a penny with an embossed image. You pick one of 4 images, put in your penny + a couple of quarters and then turn a big crank handle until your newly pressed penny comes out the other side. You'd then collect squished pennies in a little collector's folio/pouch/thing for later viewing.

I guess now that pennies are getting phased out they'll have to "upgrade" the machines to work with other coins...

> Lack of support for type-safe containers (need to be hack toghether via macros)

Are templates really so much better than macros that the latter deserve to be called a "hack"? The following two examples are both type-safe and have roughly the same semantics and #LoC:

Macros:

  // pair.h
  struct id(pair) { T a, b; };
  static inline struct id(pair) id(make_pair)(T a, T b){
    return (struct id(pair)){ .a = a, .b = b };
  }
  #undef id
  #undef T

  // main.c
  #include <stdio.h>
  #define T int
  #define id(n) n ## _int
  #include "pair.h"
  int main(void){
    struct pair_int p = make_pair_int(12, 13);
    printf("%d %d\n", p.a, p.b);
  }

Templates:

  //pair.h
  template<typename T>
  struct pair { T a, b; };
  template<typename T>
  pair<T> make_pair(T a, T b){
    return (pair<T>){ .a = a, .b = b };
  }

  //main.cpp
  #include <stdio.h>
  #include "pair.h"
  int main(void){
    pair<int> p = make_pair(12, 13);
    printf("%d %d\n", p.a, p.b);
  }

> (e.g. closing a file), there's generally not much you can do anyway

If closing a file fails then you treat it the same as how you would treat a write failure:

  int err = 1;
  FILE *f = fopen("whatever.txt", "w");
  if(f){
    if(5 == fwrite("Hello", 1, 5, f))
      err = 0;

    if(0 != fclose(f))
      err = 1;
  }
  return err;

Code which writes to files and doesn't check for errors on close is subtly incorrect, although my understanding is that kernel devs bend over backwards to make failure unlikely, probably because everybody does it incorrectly anyway.

> Typically a harbour doesn’t have one razor-thin path of traversable water. Instead there’s a clear pathway that you shouldn’t stray too far away from. The Moire system will give steering advice even if you’re in a safe area, but slightly off the main ‘beam’.

You could fix this issue by just having a second lamp (or two grills in front of the same lamp). If the two arrows point in opposite directions, you're safe. If they point the same direction, you're not.

> lambda expressions can only be passed to template functions

> there is no way to explicitly refer to the compiler-generated name for the lambda type.

"Voldemort" types. While intellectually I get the explanation for why C++/Rust lambdas are like this, I still strongly dislike them. Occasionally being unable to even articulate what something is feels like a failure in language design.

C recently got type inference via the "auto" keyword and it seemed like almost immediately there was a proposal to add voldemort types to the language.