thtroyer

@thtroyer@programming.dev

• ⁨Comment⁩ on ⁨Bill is a pro grammer⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Bill is a liability.

• ⁨Comment⁩ on ⁨Is Java Still Keeping Up with Modern Programming Languages⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Project Panama is aimed at improving the integration with native code. Not sure when it will be “done”, but changes are coming.

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Nice video about it here : youtu.be/cZLed1krEEQ

  Tldw: US DOS version actually has 2 separate impossible jumps on a level that aren’t present on the European DOS or NES versions.

• ⁨Comment⁩ on ⁨Which language you wish would really grow and reach mainstream adoption?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Wow, that looks really nice!

  I use Lua for PICO-8 stuff and it works well enough, but certain parts are just needlessly clumsy to me.

  Looks like TIC-80 supports wren. Might have to give that a try sometime!

• ⁨Comment⁩ on ⁨What are some of the best optimizations you applied to your code?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Yep, absolutely.

  In another project, I had some throwaway code, where I used a naive approach that was easy to understand/validate. I assumed I would need to replace it once we made sure it was right because it would be too slow.

  Turns out it wasn’t a bottleneck at all. It was my first time using Java streams with relatively large volumes of data (~10k items) and it turned out they were damn fast in this case. I probably could have optimized it to be faster, but for their simplicity and speed, I ended up using them everywhere in that project.

• ⁨Comment⁩ on ⁨What are some of the best optimizations you applied to your code?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I’ve got so many more stories about bad optimizations. I guess I’ll pick one of those.

  There was an infamous (and critical) internal application somewhere I used to work. It took in a ton of data, putting it in the database, and then running a ton of updates to populate various fields and states. It was something like,

  • Put all data in x table with batch y.
  • Update rows in batch y with condition a, set as type a. (just using letters as placeholders for real states)
  • Update rows in batch y that haven’t been updated and have condition b, set as type b.
  • Update rows in batch y that haven’t been updated and have condition c, set as type c.
  • Update rows in batch y that have condition b and c and condition d, set as type d.
  • (Repeat many, many times)

  It was an unreadable mess. Trying to debug it was awful. Business rules encoded as a chain of sql updates are incredibly hard to reason about. Like, how did this row end up with that data??

  Me and a coworker eventually inherited the mess. Once we deciphered exactly what the rules were and realized they weren’t actually that complicated, we changed the architecture to:

  • Pull data row by row (instead of immediately into a database)
  • Hydrate the data into a model
  • Set up and work with the model based on the business rules we painstakingly reverse engineered (i.e. this row is type b because conditions x,y,z)
  • Insert models to database in batches

  I don’t remember the exact performance impact, but it wasn’t markedly faster or slower than the previous “fast” SQL-based approach. We found and fixed numerous bugs, and when new issues came up, issues could be fixed in hours rather than days/weeks.

  A few words of caution: Don’t assume that building things with a certain tech or architecture will absolutely be “too slow”. Always favor building things in a way that can be understood. Jumping to the wrong tool “because it’s fast” is a terrible idea.

• ⁨Comment⁩ on ⁨Would the world be a better place if Google bought Gitlab?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Which they could have done a much better job with.

  It was basically just hosted SVN if I remember right, and they never added git support when it became the de facto version control system.