zovirl · HackerTrans

3 か月前議論

As long as the orbit isn't changing, pointing the antenna is not hard and can be done by hand. I've done it with a handheld yagi antenna and the ISS, which has a 90-minute orbit (and an amateur radio repeater). I used a computer program to find the next overhead transit, paying attention to start & end times and start & end azimuth. Then used a watch to know where to point the antenna during the transit: at the horizon at the start, overhead halfway through the transit, at the opposite horizon at the end. Transits were 5-10 minutes so there's plenty of time to move the antenna.

zovirl

4 か月前議論

In the same way that crypto has been speed running the history of banking scams, it seems prediction markets are going to speed run the history of gambling and insurance fraud.

zovirl

4 か月前議論

With enough cash on the line, humans are very resourceful at manipulating outcomes.

Humans already control the weather: https://en.wikipedia.org/wiki/Cloud_seeding.

We already have an example of humans sabotaging the measurement of weather: https://news.ycombinator.com/item?id=41684440. Two ranchers sabotaged weather monitoring stations in order to fraudulently collect millions in drought insurance. One of the farmhands involved ended up dead.

And we have an example of prediction markets attempting to manipulate reporting of events: https://news.ycombinator.com/item?id=47397822.

I have a hard time believing weather prediction markets will be net beneficial. The incentive for sabotage & manipulation up and down the chain seems likely to lead to worse weather predictions overall.

zovirl

4 か月前議論

Additionally, the file size of the sprite sheet image is often smaller than the combined file sizes of the individual images. (I never looked into why but expect it has to do with sharing overhead and the compression dictionary)

zovirl

6 か月前議論

Can you speak more on why glider pilots need night vision googles to fly at night but single-engine pilots don’t? Is it the risk of landing out? Or are they flying closer to the terrain?

zovirl

8 か月前議論

I agree there aren't very many. I can think of PuzzleScript, Unreal Blueprints, and Machinations (mentioned elsewhere in this thread). Perhaps this dearth is why Blueprints got so popular?

Honorable mentions might go to PICO-8's flavor of Lua (C-like but clearly designed to create a specific type of game and have a specific developer experience) and Excel (used for developing & balancing game mechanics, but usually replaced in the final product).

zovirl

9 か月前議論

I was lucky, early in my career, to work at a place which used a lot of Perl and to read Damian Conway’s book, Object Oriented Perl. It was an amazing, mind-expanding book for me. It was filled with examples of different approaches to object-oriented programming, more than I ever dreamt existed, and it showed how to implement them all in Perl.

So much power! And right in line with Perl’s mantra, “there’s more than one way to do it.”

Unfortunately, our codebase contained more than one way of doing it. Different parts of the code used different, incompatible object systems. It was a lot of extra work to learn them all and make them work with each other.

It was a relief to later move to a language which only supported a single flavor of object-oriented programming.

zovirl

9 か月前議論

And at the extremes, too much power makes a tool less useful. I don’t drive an F1 car to work, I don’t plant tulips with an excavator, I don’t use a sledgehammer when hanging a picture. Those tools are all too powerful for the job.

zovirl

10 か月前議論

http://online-go.com has an interesting anti-stalling feature: If you pass several times it checks with KataGo. If KataGo is 99% sure you will win, either player can click a button to accept that result and end the game.

zovirl

10 か月前議論

Sensei's Library is a gem from the non-commercial web! It reminds me of the C2 wiki (https://wiki.c2.com) but for Go instead of software engineering.

zovirl

10 か月前議論

Even in situations where this is true, there's almost certainly a better phrasing than "this new policy sucks," which only communicates an emotion. It is imprecise. Listeners will jump to their own conclusions about why you think it sucks.

You can acknowledge the problems more directly: "I get it, we don't have enough chairs so Wednesday is likely to be a challenge." or "I know mandatory 9-5 is going to disrupt your commute."

A bonus of the more precise approach is you can follow up with "do you have other issues with the new policy that I may not know?"

zovirl

10 か月前議論

I think the parent was complaining about mentions of CRDTs which don’t acknowledge that the problem domain CRDTs work in is very low level, and don’t mention how much additional effort is needed to make merging work in a way that’s useful for users.

This article is a perfect example: it says syncing is a challenge for local-first apps, logical clocks and CRDTs are the solution, and then just ends. It ignores the elephant in the room: CRDTs get you consistency, but consistency isn’t enough.

Take a local-first text editor, for example: a CRDT ensures all nodes eventually converge on the same text, but doesn’t guarantee the meaning or structure is preserved. Maybe the text was valid English, or JSON, or alphabetized, but after the merge, it may not be.

My suspicion, and I might be going out on a limb here, is that articles don’t talk about this because there is no good solution to merging for offline or local-first apps. My reasoning is that if there was a good solution, git would adopt it. The fact that git stills makes me resolve merge conflicts manually makes me think no one has found a better way.

zovirl

10 か月前議論

> My problem is that I cannot see how control flow works in Forth, e.g. a simple if-then-else.

What made it click for me was http://www.exemark.com/FORTH/eForthOverviewv5.pdf, specifically sections 2.3 "Loops and Branches" and 5.3 "Structures". With a slight simplification, if/else/then branching is defined in 7 words.

Two primitive words, branch and ?branch (in python because I know it better than assembly):

  def branch():
    """ branch is followed by an address, which it unconditionally jumps to."""
    ip = code[ip] # Get address from next cell in code, jump to it.

  def branch_if_zero():
    """ ?branch is followed by an address. ?branch either jumps to that address,
    or skips over the address & continues executing, depending on the value on the
    stack."""
    if stack.pop() == 0: # Pop flag off stack
      ip = code[ip]      # Branch to address held in cell after ?branch
    else:
      ip += 1            # Don't branch, skip over address & keep executing

Two helper words for forward branching. >MARK adds a placeholder branch address to code and pushes the address of the placeholder. >RESOLVE resolves the branch by replacing the placeholder with the address from the stack.

  : >MARK    ( -- A ) HERE 0 , ;
  : >RESOLVE ( A -- ) HERE SWAP ! ;

And then the actual IF, ELSE, and THEN words. IF puts ?branch and a placeholder address in code. ELSE puts branch and a placeholder address in code, then updates the preceding branch address (from an IF or ELSE) to land after the ELSE. THEN updates the preceding branch address to land after the THEN.

  : IF   ( -- A )   COMPILE ?branch >MARK ; IMMEDIATE
  : ELSE ( A -- A ) COMPILE branch >MARK SWAP >RESOLVE ; IMMEDIATE
  : THEN ( A -- )   >RESOLVE ; IMMEDIATE

コメント