879 karma · joined March 28, 2007
https://kotaku.com/unity-ironsource-merger-ad-tech-layoffs-1... https://mobilegamer.biz/inside-unitys-troubled-4-4bn-ironsou... https://unity.com/news/unity-completes-merger-ironsource
And for the younger folk, this mp3 player was the precursor to Spotify:
More recently, I’ve been teaching a 3 year old letter sounds and he loves running around finding signs saying “Dad” I found a “duh”. “Duh duh duh!” (For D). Kids really just want to hang out with you so, it’s ok to just throw in some letter sounds or number counting ideas in here and there. You’ll be surprised what they pick up!
I find the complexity to still feel awkward enough that makes me wonder if deleted_at is worth it. Maybe there are better patterns out there to make this cleaner like triggers to prevent deletion, something else?
As for the article, I couldn't agree more on having timestamps / user ids on all actions. I'd even suggest updated_by to add to the list.
Having real places is still awesome. I know the finances don't really scale, but shoutout to Lynnwood GameStop for keeping it real out there.
And RIP RadioShack. You always had a hard drive when we needed one to reinstall windows during a lan party. holds up a glass
He always says it like he isn't sure we know about buses yet making me think it’s hard to model others as separate minds with differing information until much older. But his modeling of the world logic is very solid. He can easily use multiple tools to reach high up snacks, or build complex block forts, or reason about what will happen “we will grow up and then go to kindergarten!”
(P.S: I did use Dreamweaver in the early 2000s. It was great. I’m surprised it still is running! RIP Fireworks)
To demonstrate my tweak to your idea, imagine this example code:
r, err := SomeFunction() if err != nil { return fmt.Errorf("something 1 failed: %v", err) }
r2, err := SomeFunction2() if err != nil { return fmt.Errorf("something 2 failed: %v", err) }
r3, err := SomeFunction3() if err != nil { return fmt.Errorf("something 3 failed: %v", err) }
In the current proposal it would turn into this:
r := SomeFunction() ? { return fmt.Errorf("something 1 failed: %v", err) }
r2 := SomeFunction2() ? { return fmt.Errorf("something 2 failed: %v", err) }
r3 := SomeFunction3() ? { return fmt.Errorf("something 3 failed: %v", err) }
My first suggestion is to keep `err` variables visible. It ends up being not much longer, but it is much more readable and Go-like:
r, err := SomeFunction() ? { return fmt.Errorf("something 1 failed: %v", err) }
r2, err := SomeFunction2() ? { return fmt.Errorf("something 2 failed: %v", err) }
r3, err := SomeFunction3() ? { return fmt.Errorf("something 3 failed: %v", err) }
My second suggestion is to require ? to always have a block, and also allow them to "chain" so only the last statement needs a block:
r, err := SomeFunction() ? r2, err := SomeFunction2() ? r3, err := SomeFunction3() ? { return fmt.Errorf("something 1, 2 or 3 failed: %v", err) }
As you can see this is much shorter! Having the block is always required at the end of the "chain" of question mark statements is more consistent with how `if` statements require a block currently. It also makes the `return err` flow also always visible (no return magic). It also also has a huge advantage of it being much harder to miss a question mark syntactically. as a question mark without a block would be a syntax error.
For example, this is an error:
r, err := SomeFunction() ? // <-- compile error: missing block after ?
And also this is an error:
r, err := SomeFunction() ? r2, err := SomeFunction2() // <-- compile error: missing block after ? r3, err := SomeFunction3() ? { return fmt.Errorf("something 1, 2 or 3 failed: %v", err) }
Thanks for listening! Curious what folks think.
As to rendering, I’ll be honest and say that my code has moved more towards client-side (using ConnectRPC and my framework ojjs.org—-shameless plug :), but I love that you have had success with a different path. Super interesting, and thanks again!
So if so if Jet Set Radio was released June 2000, you can look for related papers a couple years before to see if new techniques were appearing. And, in fact, they were!
Disney paper (1998) on texture mapping for cell shading (the color of a cartoon):
https://media.disneyanimation.com/uploads/production/publica...
NYU paper (1998) applying outlines to 3d objects (the black outline of a cartoon) :
https://mrl.cs.nyu.edu/publications/npr-course1999/hertzmann...
To contrast, I’ve been thinking a lot about the Amazon Colorsoft launch, which had a yellow band graphics issue on some devices (mine included). Amazon waited a bit before acknowledging it (maybe a day or two, presumably to get the facts right). Then they simply quietly replace all of them. No recall. They just send you a new one if you ask for it (mine replacement comes Friday, hopefully it will fix it). My takeaway is that it’s pretty clear that having an incredibly robust return/support apparatus has a lot of benefits when launches don’t go quite right. Certainly more than you’d expect from analysis.
Similarly I haven’t seen too many recent reports about the Apple AirPod Pros crackle issue that happened a couple years ago (my AirPods had to be replaced twice), but Apple also just quietly replaced them and the support competence really seemed something powerful that isn’t always noticed.
Colorsoft: https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
AirPods Pro: https://support.apple.com/airpods-pro-service-program-sound-...
Honestly, I think now it’s just better to go to work/school in the dark to get an hour more after work to play/be in the world. Obviously each city is different, but Seattle is miserable in the winter and it would be way more fun to have sunset at 5:15pm instead of the current 4:15pm. People don’t play catch or go to parks before school, they do it after so the darkness is partially painful for loosing time to hang with kids.
That said, the anecdotes about the 70s are super interesting. I was not alive then, but I wonder if work schedules were quite a bit different from they are now to account for the difference in thinking? I know plenty of people leaving at 7am to beat traffic across the bridge (well before sunset with or without dst). Perhaps in the 70s people just left at 7:30am specifically to make it to work at 8am and the sunset time mattered more then our world of 2 hour rush hour and hybrid remote work?
Kidding aside, I agree completely that syntax isn't the important part. For interviews I think of it more as a sign the person is "warmed" up in a language. If they code in Go or Rust all day currently, then I expect a bit more of the syntax to be known for that language, but it's more a tell on what they actually do all day then what they can do in a week or two of learning.
Linear Algebra was quite possible to learn while in college as it wasn’t needed in the first few cs classes (useful for ai/ml/graphics)
After that my favorites were game theory and discrete math. They are quite practical in a way that fills out the way you can reason about the world. Again, definitely not needed before you start school.
I’m still waiting for calculus/ to be useful day to day, but then again I’m not doing engineering/physics simulation software where it is essential.
Either way it’s a bold move. It’s clearly easier to type and say. I wonder if they found GPT is just too unpleasant to say so trying to switch the brand is worth it to them.
I suspect thinking is similar, which brings up questions about LLMs as well. We all can now quickly write hundreds of generic business plans, but knowing what to focus on first is still the hard part.