Sometimes the answer can be “I reject the premise.”

I’m sure you’ve had conversations where that’s the answer you want to give.

> 3D game is another beast altogether and linear algebra needs to be very solid for that.

Or you can use an engine, like Unity.

Edit: you responded and then deleted a post about "games that don't look like Unity on Unity". Ignoring that the looks of a game usually matter less in the long run than gameplay, a very, very short search shows that Escape from Tarkov[0] is made in Unity.

https://en.wikipedia.org/wiki/Escape_from_Tarkov

The reason why I deleted it was because Subnautica one of my favourite games was written in Unity. I never could have guessed.

It seems I've underestimated Unity, thank you for changing my mind!

>any "on" time is costing me usage in the long-long-long run and I'd rather have my monitor last 5+ years than ... 2 or 3.

Going from dark gray to pure black isn't going to halve your monitor expectancy, if it makes a difference at all. Due to how human perception works something that's merely dark gray is actually orders of magnitude brighter than pure white, or even 50% gray. Therefore most of your burn-in is going to be driven by bright content like photos or white text, not whether you're using 5% gray vs pure black.

Frameworks and packages, sure. I’m not sure I would agree with APIs.

ActiveAdmin is best in class, Rails is fantastic; but there’s a lot of insanity in the API for a language that “gets out of the way” and “just works”

Slice is my favorite example. (It’s been a bit since I’ve used it)

  [0].slice(0, 100) == [0]
  [].slice(0, 100) == … 

exception? Or nil? Why does it equal []?

For a “give me an array back that starts from a given, arbitrary index, and auto-handle truncation” not having that behavior continues to confuse me from an intuitive perspective. Yes, I understand the source of it, but why?

Because [] is an array with nothing in it, and [0] is an array with something in it.

So saying “give me the array containing the first 100 elements of this array with one element” would obviously give you the array with one element back.

Saying “give me the array containing the first 100 elements of this array with zero elements” would follow that it just gives the empty array back.

On top of that, because ruby is historically duck-typed, having something always return an array or an error makes sense, why return nil when there’s a logical explanation for defined behavior? Ditto for throwing an error.

Seems thoughtfully intuitive to me.

Yeah, returning an empty array is pretty much exactly what I would expect given the first example. It would be a lot weirder to me if you were allowed to give an end index past the last element only if the array happened to be non-empty.

Sorry, I mis-spoke earlier, this is what I should have shared:

  [].slice(5, 100)

^-- *THIS* either returns nil or throws an exception.

Edit: Longer example:

  puts "[1, 2, 3].slice(1, 100) -> #{[1, 2, 3].slice(1, 100).to_s}"
  puts "[1, 2, 3].slice(3, 100) -> #{[1, 2, 3].slice(3, 100).to_s}"
  puts "[1, 2, 3].slice(4, 100) -> #{[1, 2, 3].slice(4, 100).to_s}"

Yields:

  [1, 2, 3].slice(1, 100) -> [2, 3]
  [1, 2, 3].slice(3, 100) -> []
  [1, 2, 3].slice(4, 100) -> 

So, there is a behavior difference between "array a little too short" and "array slightly more too short" that creates unexpected behavior.

That's not a big surprise in a tiny example like this; but if you expand this out into a larger code base, where you're just being an array and you want the 100 through 110th values for whatever reason - say it's a csv. Suddenly you're having to consider both the nil case and the empty array case; but then why are they different?

Interesting! From playing around with it, seems like if the start index is exactly the same as the length, it returns empty array, but if it's further than that it returns nil. That's certainly not something I would have been able to predict, so I'd also be curious if anyone happens to know the explanation for it. My instinct is that it does seem like the type of edge case that might come up with a way to implement it tersely, but that's not a particularly good reason to leak that in the form of user-facing behavior, so hopefully there's a better explanation.

Some additional things I discovered when trying to figure out why it might work like that:

    * the behavior also seems consistent whether using `array.slice(a, b)` or `array[a..b]`
    * `array[array.length]` and `array[array.length + 1]` both return nil

the docs say... if index is out of range return nil. the edge case is that if you specify the exact end index of the array and want a slice of that index to 100 it will return an empty array. if you go out of bounds it informs you that you are out of bounds with nil. not sure it's the best api but probably is mimicking some C api somewhere as a lot of ruby does that. that said it will never error on this alone but it will almost certainly error if you chain it with something not expecting nil.

The easiest way to get around that if you are not carefully using the ranges would be to do `Array(array.slice(a, b))` as that will guarantee an array even if it's invalid. you could override slice if you really wanted to but that would be a performance penalty if you are doing it often.

Indeed. I had heard that it was a carryover from C; but for an "implicit is better than explicit" and "magic ducktyping, it just works, I promise" language, like Ruby, this feels like a direct contradiction to its intended behavior and this specific example has always stood out to me in a "... but why?" sort of way.

Yeah, I'd argue that it would be less confusing to return the same thing even if it's inconsistent with some C API that plenty of Ruby programmers might never have encountered. I'm honestly not sure I even understand what the C API is that's being referred to; slices and bounds checks aren't things I typically associate with being built into C.

looked into it more and the docs say that an index out of bounds will return nil. also says if offset == size and length >= 0 it will return an empty array.

``` If offset == self.size and size >= 0, returns a new empty array.

If size is negative, returns nil. ```

either way if you are doing stuff with arrays and not checking bounds you can throw an `Array(some_array.slice(x, x+100))` and it will always behave.

Sure, the docs seem to be accurate, but that only explains "what will this do?", not "why is this what it will do?" It's not what I expect most people would come up with if they designed this API, so I have to wonder why they didn't pick something more intuitive

Especially because in ruby

[0, nil, nil, nil, …x100, nil] is the same as [0] in terms of access.

In both cases, trying to access the 100th element (e.g. [0][100]) will give nil.

because it's meant to be a more functional language. if slicing an array out of bounds threw an error it would be java.

[].slice(0, 100).each do |x| puts x end

that shouldn't be an error and it seems to be the principle of least surprise imo.

Sorry, I mis-spoke earlier, this is what I should have shared:

  [].slice(5, 100)

^-- *THIS* either returns nil or throws an exception.

( I made the other comment like this longer, please use that one for context )

Great Britain, even more North, has viable solar on its Southern edge.

As a complementary source of energy, yes, especially in summer (because the flip side of being north is that your summer days last longer).

But in winter, you'll have something like 2-5% load factor on your solar panels…

Solar has always been a part of a wholistic strategy. We’ve known this ever since the sun went down at night and we had to compensate for it.

True, but then why claim unrealistic figures like op and their "90% of his electricity usage"…

> strategy

Umm, so we still have to build enough traditional (and, ideally, dispatchable) generation capacity to make sure we can cover our electricity needs during those periods in winter where it's very cloudy and it's not windy?

eg Jan 2025

https://www.theguardian.com/money/2025/jan/22/weather-bomb-e...

"Cloudy and still weather has caused Great Britain’s renewable energy output to fall to near zero this week"

"Britain’s wind power output fell to just above zero on Wednesday, which, combined with the cold, dark weather, caused the market price for electricity to climb to almost £250 per megawatt-hour at auction, or almost seven times the average price before the pandemic"

"The sudden drop-off in renewable energy due to dull windless winter weather, known as dunkelflaute in German, has also forced the system operator to pay gas power stations more than £500/MWh to run on Wednesday evening when household demand is expected to reach its peak.

The weather conditions – the third dunkelflaute of the winter so far – left Britain’s electricity grid reliant on gas-fired power stations. They accounted for more than 70% of power generation at points on Wednesday."

What is intimacy?

I wonder if teaching an LLM how to write Prolog and then letting it write it could be a great way to explore spaces like this in the future. Other people in I wonder if teaching an LLM how to write Prolog and then letting it write it could be a great way to explore spaces like this in the future.

I only ever learned it in school, but if memory serves, Prolog is a whole "given these rules, find the truth" sort of language, which aligns well with these sorts of problem spaces. Mix and match enough, especially across disparate domains, and you might get some really interesting things derived and discovered that are low-hanging fruit just waiting to be discovered.

The DARE program just had to tell the truth, but they didn’t and it made everyone question how bad everything really was, if pot wasn’t a problem.

Full agree here. Unfortunately, history is what clarifies why pot is SO HUGE now rather than being something indifferent about, like it should be.