• 1 Post
  • 14 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2023

help-circle










  • CatPoop@lemmy.worldtoProgramming@programming.dev...
    link
    fedilink
    English
    arrow-up
    9
    ·
    1 year ago

    For my sins I spend a significant part of my time maintaining smalltalk, and it most definitely is not productive.

    The syntax is ugly and cumbersome when you start chaining messages. Any advantages the evangelists tout are available in modern languages without the baggage of this dead one.

    Today if you want something ‘simple, flexible, interactive’ (interpreted, GC and likely faster) python would almost certainly be a better choice.


  • Should have no problems. Couple of things to check on the TV settings menu, make sure the zoom is set to ‘fit’ so that there is no border/overscan, if there is a ‘game’ or ‘low latency’ mode enable it; otherwise turn off all picture enhancements (e.g. LG clear view / image smoothing) as they are no bueno for gaming.



  • If you haven’t already done so i’d recommend enabling nullable types, at the very least it should make your code more robust against this particular error, and may help narrow down where exactly the null is set. I’ve only seen one null reference exception since I turned this feature on, and it was because I mis-used the null-forgiving operator…

    The debugger is important in the immediate stage of coding, but high quality logs will make your life much easier through all stages of the software development lifecycle.

    Regarding real-time / system software, all IO and new threads must always be wrapped in exception handlers, and every handler must do something in the catch block, if nothing else log the exception, I usually dump the stack trace as well if I’m not really expecting it to reach a particular block, most of the time the stack trace makes the debugging trivial.

    If you are working with sensors/devices, it’s good practice to write a driver, and also a device simulator down to the byte/protocol level, then you can inject faults and ensure your app can handle them. Don’t be afraid to throw exceptions, e.g. if your sensor message parser doesn’t understand the format, throw a FormatException; then you’ll safely walk back up the stack and combined with good logs the issue should be straightforward to diagnose.

    Multithreading is a minefield, but you can eliminate a whole class of errors (race conditions) by embracing async/await. Avoid side effects at all costs and try to write pure functions only; never use ‘flags’. Use the concurrent collections, and try to avoid locks where you can; if you must, get in and out of the critical section as fast as you can, or you will degrade performance and increase the possibility of deadlocks.