91–100 of 113 posts
> Division is much slower than multiplication (unless using approximation). Dividing many numbers with one number can be optimized by firstly computing reciprocal then multiply by reciprocal. Is this a general fact or specific to a language?
The biggest trap of all: building things that no one, including yourself, wants
Also as a corollary, I was thinking about games from the 90s I spent hundreds of hours playing back then earlier today. Bolo and Escape Velocity in particular come to mind. They were "simple" games with immense depth. But after some fruitless searching, all I find is scattered questions and comments over the last few years looking for modern equivalents are a handful of recommendations for games that are no longer developed or are defunct.
There's clear prior evidence of both success and lack of modern supply. Want to have a minimally minor successful game with established nostalgic audience? Make a new version of EV that is that game at its core. Don't be fancy, just do the thing Ambrosia did. Expand from there.
The simple model is look forward, and also look back. The first itch is small. For yourself. Find some others with a similar itch.
The hard part is pushing your idea into something more people want. That's where pg's 2013 article comes in to play. That's the hard part.
But that leaves a huge space between 0 and 10 where someone can find a successful niche.
Hell I've thought about trying to make a modern EV. It's tantalizing. But I've never made a game in my life. Ok I've rewritten Game of Life a lot. Good concept to try new ideas with. But the amount of work for a solo dev trying to recapture that original magic with no background in game dev is daunting.
> A method that returns Optional may return null. projects that do this drive me bananas If I had the emotional energy, I'd open a JEP for a new @java.lang.NonNullReference and any type annotated with it would be a compiler error to assign null to it public interface Alpha {} @java.lang.NonNullReference public interface Beta {} Alpha a = null; // ok Beta b = null; // compiler error javac will tolerate this Beta b; if…
Earlier quoted context omitted.
Often people use optional or nullable types as a convenient approximation to an Either type.
I still don't see why it would be a problem merging then down even when used like an either. If there is no value then there is no value.
Earlier quoted context omitted.
In what context would you not want to treat Optional.of(null) and null as the same? It shouldn't be a big deal.
The None branch of each level of a nested Optional has a different meaning.
Earlier quoted context omitted.
Often people use optional or nullable types as a convenient approximation to an Either type.
I still don't see why it would be a problem merging then down even when used like an either. If there is no value then there is no value.
{}
{ "foo": null }
{ "foo": 42 }
struct Whatever {
foo: Option>,
}
I'll often use this in PATCH endpoints, where not-present means to leave the current value alone, null means to unset it, and a value means to set to that value.
> Java, C# and JS use UTF-16-like encoding for in-memory string That’s incorrect for Java, possibly also for C# and JS. In any language where strings are opaque enough types [1], the in-memory representation is an implementation detail. Java has been such a language since release 9 ( https://openjdk.org/jeps/254 ) [1] The ‘enough’ is because some languages have fully opaque types, but specify efficiency of some opera…
> > Java, C# and JS use UTF-16-like encoding for in-memory string > > That’s incorrect for Java, Maybe so, technically, but if you Base64 encode a string in a language that uses UTF-8 (or another UTF-16 with another endian) and decode it in Java, Java's UTF-16 representation will be the problem you will be dealing with.
Earlier quoted context omitted.
A mutex would be the most trivial example. I don't believe that is possible to implement, in the general case, with only acquire-release. Sequential consistency mostly become relevant when you have more than two threads interacting with both reads and writes. However, if you only have single-consumer (i.e. only one thread reading) or single-producer (i.e. only one thread writing) then the acquire-release semantics en…
> A mutex would be the most trivial example. I don't believe that is possible to implement, in the general case, with only acquire-release. Wait, what? So you're saying this spinlock is buggy? What's the bug? https://en.cppreference.com/w/cpp/atomic/atomic_flag.html
Earlier quoted context omitted.
I question the wisdom of even having Optional in a language with nulls. It would raise some eyebrows if a function in Python returned an Optional type object rather than T | None. You have to do a check either way unless you're doing some cute monad-y stuff.
It works quite well in Scala, which still tolerates nulls due to being in the JVM and having Java interop. Realistically nothing in the language is going to return null, so the only time you might have to care is when you call Java classes, and all of the Java standard library comes scalaified into having no nulls. And yes, there are enough monadic behavior in the standard library to make Option and Either quite usef…
I still remember when Java 9 introduced modules. And I’m currently pulling my hair because Java 21 renamed all javax.* into jakarta.* because Javax was a trademark of Oracle, and all libs now require a “-jakartax” version for JDK 21.
But somehow I still have to deal with nulls everywhere and erased-at-runtime generics because Java loves backwards compatibility so much. The simple fact all libs released a “-jakartax” proves the entire ecosystem is fully maintained (plus CVEs means unmaintained libs aren’t allowed in production), so they could very well release a -jdk25 version with non-null types.
> A method that returns Optional may return null. projects that do this drive me bananas If I had the emotional energy, I'd open a JEP for a new @java.lang.NonNullReference and any type annotated with it would be a compiler error to assign null to it public interface Alpha {} @java.lang.NonNullReference public interface Beta {} Alpha a = null; // ok Beta b = null; // compiler error javac will tolerate this Beta b; if…
I question the wisdom of even having Optional in a language with nulls. It would raise some eyebrows if a function in Python returned an Optional type object rather than T | None. You have to do a check either way unless you're doing some cute monad-y stuff.