Hotland - Bad Opinion Zone · liquidex's treehouse

“Hotland - Bad Opinion Zone”
log verbosity levels are stupid
- because when should you use any log level other than error, warn, or info?
  - for debug info that doesn’t affect most users, there will always be lower verbosity levels than info, but in my experience these are always extremely specific, and clumping them all into debug or trace doesn’t make much sense
    in that case I believe it is better to declare separate channels that can be filtered individually, and use info for everything
    you say info sounds wrong for debug info? well,
    guess what, it’s debug info
    the very concept of logs is to dump a load of (debug) info for later analysis, so making some distinction between debug and non-debug info while logs are inherently for debugging seems a little silly to me
  - use severities instead of verbosities
    error is “OH SHIT OH FUCK UHHH”
    warn is “ding ding ding! something ain’t right, but I’ll carry on”
    info is just that - info
    and there is really no need for anything lower, because guess what: debug and trace and Display and Verbose and VeryVerbose and what have you - they’re all just more info for you
    and while writing logging code it’s always hard to decide which info should be stuffed into which verbosity, because which info will be interesting to you at the time you read logs depends on what you’re looking for at a given moment
- this is something I haven’t tried yet, but one day I wanna build a logging framework one day that associates severities with whole categories rather than individual log messages
  - but at that point, do we even need severities at all? would a hierarchy of categories suffice?
  - I have no clue how well that will work but it would be pretty interesting
tracing is better than logging
- information about time spans is very valuable for profiling
- and you do not have to worry about “should I log before I start the operation, or after I end the operation?”
- additionally, traces made of spans are way easier to visualize than tonnes of logs
  - if you’ve never tried Perfetto or similar tools, I highly recommend giving it a shot
- I also imagine visualizing traces live in your CLI could yield a very nice user experience, with a visible progress indicator as to what eg. your compiler is working on right now at a glance, reassuring you that it is not stuck on some while (true) {} in constant evaluation
  - perhaps emitting warnings along the road for things that take alarmingly long, so that you can keep your build times in check
  - though printing to stdout is quite slow, so perhaps limiting the frequency or depth would be a worthwhile thing to do
don’t use RefCell<T>
- usually if you have to resort to RefCell<T>, it means something is wrong with your architecture
  - Cell<T> less so but still you should avoid it whenever possible
  - Rc<RefCell<T>> is an immediate red flag when I read someone’s code. it means they don’t really know what they’re doing and are just trying to sidestep the language
- it’s really not that hard to avoid, try bumping your resources up a scope and borrow them from there
- using RefCell has a few disadvantages
  - first, RefCell is literally turning off the borrow checker
    or really deferring it until runtime, but then what’s the point. Rust’s borrowing rules are meant to prevent bugs, not cause more of them
  - second, your program can now panic in unexpected places, because it turns out runtime borrows can be really hard to predict
    as evidenced by a random crash I once got while using druid which was caused by a overlapping mutable then immutable borrows at runtime
    therefore maybe uhhh… don’t use it in libraries? :pleading:
  - third, it incurs a runtime overhead for the borrow checking, which in 99% of cases is totally unnecessary
    (this is more about non-pessimization rather than premature microoptimization, so don’t yell at me with your “it’ll be fast enough” arguments please)
  - fourth, and this one is extremely easy to spot - your code becomes really verbose!
    yes please, .borrow() me everywhere!
    and you end up with lots of temporaries because of the Ref<'b, T> guards you have to keep in scope.
    remember that you cannot do &ref_cell.borrow().some_field because that would drop the temporary Ref<'b, T> guard after the expression ends
None or Invalid cases in enums are a bad idea
- by having them, you’re forcing your users into an API that forces them to think about the invalid case every time they read the value.
  - you’re repeating the million dollar mistake - null
  - instead, use an explicit Option<T> or std::optional<T> or T? or … when you need to represent a possibly-invalid case
NaNs should crash the program
- any time I see a NaN I cry inside knowing how much pain debugging it’s gonna be.
- I’d rather have the program crash and burn at the point a NaN is produced rather than have to sift through all the math to find that one division by zero I didn’t account for
- this does influence performance negatively, but it saves so much debugging pain and finding out which non deterministic scenario causes a NaN to propagate through the system
  - worst case scenario you pull a Rust and disable those checks on release mode. that does work, but I don’t like the idea of disabling numeric safety checks on release mode either.
operator overloading is good, but getters and setters are not
- this one stems from an argument I had today, so I’ll write my thoughts for future generations’ enjoyment here
- I’ll start by prefacing that I think operator overloading is good iff it’s implemented in a way that a single operator has only one, well-defined meaning
  - this means + really means addition and nothing else.
    this is practically impossible to enforce at a language level - what prevents the standard library authors from overloading + to mean string concatenation after all?
    however we can at least do our best by writing good defaults and coding standards that gently suggest what to do and what not to do
    for example, allow users to define their own arbitrary operators that are explicitly not addition, to incentivize inventing new syntax for these things
    the way I’d like to do it in my dream language is by a few means
    (+) is defined to be a polymorphic operator which calls into a module implementing the AddSub interface, which means you have to implement both addition and subtraction for (+) to work on your type rokugo let AddSub = interface { type T fun add (a : T) (b : T) : T fun subtract (a : T) (b : T) : T }
    
    fun (+) (a : let T) (b : T) : T use AS : AddSub with { T } = AS.add a b
    note how this operator does not have any effects declared on it - this means addition and subtraction must not have any side effects such as I/O
    the (add AND subtract) rule enforces types like strings to take a different operator, because (-) does not have a well-defined meaning on strings
    is "foobar" - "bar" == "foo"?
    by extension, is "foofoobarbar" - "bar" == "foofoobar" or "foofoobarbar" - "bar" == "foofoo"?
    maybe characters are subtracted from the left string one by one? such that "foobar" - "bar" == "\x04\x0e\xfcbar" (wtf)
- so now getters and setters: what’s so bad about them?
  - the problem is that given the rule above - one operator means one thing - getters and setters completely destroy your assumptions about what = might do
    what’s that? you didn’t expect camera.angle_z = 420 to throw because 420 is out of the [-π/2, π/2] range? oops!
    what’s that? you didn’t expect camera.angle_z to return a different value every time you access it? oh, well!
    at least when it’s spelled camera.angle_z() it suggests that it might do something weird, like access the thread RNG.
  - not to mention all the infinite recursion annoyance that sometimes happens when implementing them manually
    this is less of a problem in languages that feature automatic generation of getters and setters - such as Kotlin kotlin var someVariable: String get private set // no infinite recursion to be seen here! but it’s still an issue in eg. JavaScript, where one mistake can send your call stack down the spiral: javascript class Example { #someVariable = "";
    
    get someVariable() { return this.someVariable; } // typo!!!! set someVariable(value) { this.someVariable = value; } // typo again!!!!!!!!!! dammit! } and the error is not caught until runtime.
    it’s easy to fix but still an annoyance whenever you write a getter/setter pair.