HN user

nivertech

1,979 karma

[ my public key: https://keybase.io/nivertech; my proof: https://keybase.io/nivertech/sigs/TSPizHrahhxd9Q1ZrIOFu3_73baE_0_XgUQTWapr4Zs ]

  - Distributed Systems
  - DDD / CQRS / Event Sourcing
  - Erlang/OTP, Elixir/Phoenix/Absinthe/LiveView, Elm
  - kdb+/q
  - GraphQL, MQTT, Pub/Sub, WebSockets, Long Polling, etc.
  - PostgreSQL, Redis, DynamoDB, Riak
  - AWS / GCP
  - GPU Computing (OpenCL, CUDA)
  - Agent-based Modeling/Simulations (ABM), NetLogo
Posts15
Comments1,577
View on HN

In ancient Egypt, there were various trade unions, usually organized by profession

One of the most interesting was the thieves' union

Suppose someone stole yr carpet at night, and in the morning you'd go to the office of the head of the thieves' union, pay 25% of the carpet's value, and get it back. Much better than modern insurance!

This Soviet project developed two Russian-language PLs: Robic[1] and Rapira[2]. Robic was similar to Logo, but unlike Logo, which had only one actor - a turtle, Robik had several: a Train, an Ant, a Painter, and so on

Rapira was more like SETL + Python. It was a dynamic interpreted PL with a rich set of compound data types, such as sets, records (associative arrays), and so on. Compared to the contemporary BASIC, it was ADVANCED

Like Logo, Robik was used to teach programming to kindergarthen-age children, while Rapira was aimed at high school students

---

1. https://en.wikipedia.org/wiki/Robic / https://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D0%B1%D0%B8%D0%BA

2. https://en.wikipedia.org/wiki/Rapira / https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%BF%D0%B8%D1%80...

It's better to first show truth tables, then K-maps, and only then logical formulas.

But the main question is: does this FP2 have any real applications? Maybe it could be useful when only one operand is FP2? Especially for vectorized math.

1. The problem is with using HTTP for APIs, not with GraphQL. HTTP was designed for rich (hypertext) documents, not for APIs. So layering GraphQL or any other APIs over HTTP is a hack.

2. GraphQL is useful for small remote teams b/c of mandatory staticly-typed schema and built-in schema documentation. Otherwise it's lots of back-and-forth between backen, frontend, QA, etc. You forced to use external tools like Postman collections, and still having communication problems.

After years of debate and confusion, the GraphQL Working Group has reached a historic decision: starting with the October 2027 spec release, all GraphQL responses will return random HTTP status codes between 100 and 599.

Additionally in order to make GraphQL AI Agents friendly, the GraphQL response body will be switching from JSON to Markdown.

Tickets Are Prompts 4 months ago

Imagined vs discovered tasks

The way to really figure out what needs to be done is to start doing real work.

https://basecamp.com/shapeup/3.1-chapter-10#imagined-vs-disc...

  imagined   tasks ==      Jira
  discovered tasks == Dark Jira
IMO, tickets for planned work are an anti-pattern. Tickets are good for reactive work: bug reports, support, etc. Use Kanban board for tracking them.

Planned work should be organically discovered from the plan by the developers (or agents) who will be implementing it, not assigned via Jira tickets by the project manager. Shape Up recommedns using Hill Charts for per-scope (vertical slice) progress updates.

Claude Code's /voice mode isn't very accurate comparing to other speech-to-text (e.g. Google Translate).

Also it takes about 500ms to activate after you press SPACE, so the initial words are missed out. It took me some time to realize it.

Does Handy has a better speech-to-text accuracy? Is there an activation delay?