whilenot-dev

> No-questions-asked returns

That's the Right of withdrawal[0] by EU law, though. Do you mean something else?

I mean, sure, smaller shops might not cover the costs for the return shipping, but I don't really mind.

[0]: https://europa.eu/youreurope/citizens/consumers/shopping/ret...

Varia is a nice GUI and download manager built around aria2: https://giantpinkrobots.github.io/varia/

Losing control of the vehicle in birds-eye view felt closer to reaching my human limits than reaching the vehicle limits, I really missed that with the change to 3D. The whole city also truly felt like it was designed around the birds-eye view, like the group of Hare Krishna (GTA I) or Elvis impersonators (GTA II) behaving like virtual ants when rushing into them was always something magical and wasn't quite the same in 3D.

What are all the names for the category of such software... "Self-defense Software", "Busy Simulation Software", "Faux Work Software", "Fake Meeting Software"[0], "Virtual Meeting Simulator"[1], "Prank Screens"[2], ...? Are there many others?

[0]: https://fakemeeting.app/

[1]: https://z.tools/t/fake-meeting

[2]: https://www.whitescreen.online/

I have the same question, especially since any CLI output can be stored explicitly in some variable or temp file. What's the advantage of storing the output implicitly?

If the data don't need to be processed in batches by category, and if the category is derivable from an data item alone, I don't really see the benefit you're proposing.

Even worse, by splitting one state (and one derivable category from that state) into two separate arguments for do_thing, something can be off rather badly. I'd then feel the need to design an assertion of the relation of the arguments in order to make things bearable again:

  def do_thing(category, data):
    # to avoid shadowing lets rename your function `category` to `category_from_item`
    assert all(category == category_from_item(item) for item in data)
    ...

But that would add a third loop to your two loops, and would duplicate the computation of a category.

Instead, if category would be a property of data item:

  class DataItem:
    
    @property
    def category(self):
       ...

...and the do_thing function would work on a single data item, then it'd just become a simple matter of one for loop and one match/case:

  def do_thing(item):
    match item.category:
      case ...:
        ...

Had one too, it's rather on the loud side of clicking and the build quality is great.

I presume you didn't get the "Let me sign a deal with the devil!"-part OP mentioned in TFA then.

Sure, that's all correct, of course a performance hit would be noticeable if thousands of dependencies would need to be checked additionally.

OP is talking about type stripping nonetheless, and I'd put type stripping into the same ballpark as reading ambient declarations, performance wise.

Type stripping can and does ignore tsconfig.json files, from the provided link:

> Node.js ignores tsconfig.json files and therefore features that depend on settings within tsconfig.json, such as paths or converting newer JavaScript syntax to older standards, are intentionally unsupported.

Of course import aliases and such features would break.

> A mismatch would mean you would get type errors inside the library code

OP doesn't want the types to be checked, they want the types to be stripped. Type stripping ignores tsconfig.json files and any of its features, see: https://nodejs.org/api/typescript.html#type-stripping

Such a tool is very helpful for editors who manage video footage, and since 12K cameras are affordable now, I'd guess 12K actually refers to the resolution here.

iPhone 13 mini (and ex-SE) user here, this phone looks great!

I like the minimal and solid looking design. I think the real keyboard is an interesting and welcoming compromise for its width. If the built quality is on point, I'd see no issue with the price.

Full Android also means there's no restriction in the apps I'd need. GrapheneOS on it would be great.

I appreciate the minimal color options - I have this thing where all my technical devices running software should be in all black, and any colorful details would just bother me a bit (looking at "playful" design choices like the lime green switch on the Fairphone 6).

Quick nitpick at their marketing team: "compact by design, made for one hand." can't possibly be true with a real keyboard on a phone.

I think you should always include the iPhone SE in those numbers. It had similar dimensions, was cheaper and even more minimal. If it weren't for the SE, I would have picked a Mini right away.

> the promises are still async on the microtask queue. you seem to be showing syntax, not semantics

Well, GP doesn't want to get rid of concurrency, do they? They are talking about syntactic preferences when they want to "make every function async". I just showed them a way to make every function "some-form-of" sync, so they'll know how to change every function according to their preferences, either async or sync.

> But then would it make sense to make every function async?

No, that doesn't make sense at all! You're being too reductionist...

I/O has its place in every real world program, and the true limitation (or what you call a "problem") are the single-threaded runtimes of JavaScript. It's not a question of whether you should mark your functions async or not, as if it's an issue of consistency in the call-tree of your program. The true question should rather be whether your functions are I/O-bound (and would actually block the single-threaded event loop) or are solely compute-bound.

You're forgetting the fact that async/await in JavaScript was a historical design choice to prevent the callback-hell that came with single-threaded concurrency. So if you'd want to get back to that callback-hell (and convert async functions back to "some-form-of" sync), you still can[0]:

  // some dummy async function that doesn't really do any I/O
  async function add(
    a: number,
    b: number,
  ): Promise<number> {
    return a + b;
  }

  // convert async function back to sync to enjoy callback-hell again
  function addUnpromisified(
    a: number,
    b: number,
    cb: ((result: number | null, reason: any) => any),
  ): void {
    add(a, b)
      .then((result) => { cb(result, null); })
      .catch((reason) => { cb(null, reason); });
  }

You can think of async/await as an evolution of generators[1], as every await yields control back to the event loop. I'd actually encourage you to write some of your programs' behavior with generators if you've never done that before. Generator functions will yield control back to the caller, which is an interesting way to design programs when the caller is you instead of the event loop.

It's in Python, but David Beazley still has one of the best explanations on that topic, and shows the how and why you'd want to design an event loop live on stage[2].

[0]: https://www.typescriptlang.org/play/?#code/PTAEGcHsFsFNQCYFd...

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

[2]: https://www.youtube.com/watch?v=MCs5OvhV9S4

Debatable, but I think that Flock sells a product that does actively more harm to society than anything from Oracle ever has.

Multiple things can be true at the same time... do you think the seller doesn't want a closely surveilled world with no exits?

Besides, money keeps businesses in the economy afloat, it's an artificial good with (more or less) constant value. Money's a systematic means to an end and rarely an end goal, its purpose is the transportation of value, and not the communication of value.

I feel like your definition of Art is too simplistic and incomplete. At least since Joseph Beuys we know that "anything can be Art", and it's just a matter of how an "expression of an idea" is used to lift something up to the status of being Art. Crafts, as practices, are not excluded from that potential.

While some artists turn the labor-intensive aspects of crafting into a part of their expression (including any angles on tradition and social-economic factors), like Ai Weiweis[0] installation Sunflower Seeds[1] in the Tate Modern in London, others might focus on the community aspect of crafting as part of their media, like how Thomas Hirschhorns[2] installation Musée précaire Albinet[3][4][5] close to Paris takes crafting as a means to "be present and produce something together on location", as "agreement", as part of a community in a public space, and as inclusion of anybody beyond differences in the understanding of Art. AFAICR he could even get the Mona Lisa from the Louvre for a few days to exhibit it there.

Besides, I think it's safe to say that any work in the field of Performing Arts is based on an analysis of their craft.

[0]: https://en.wikipedia.org/wiki/Ai_Weiwei

[1]: https://en.wikipedia.org/wiki/Sunflower_Seeds_(artwork)

[2]: https://en.wikipedia.org/wiki/Thomas_Hirschhorn

[3]: https://www.thomashirschhorn.com/musee-precaire-albinet/

[4]: https://www.thomashirschhorn.com/about-the-musee-precaire-al...

[5]: https://fr.wikipedia.org/wiki/Mus%C3%A9e_pr%C3%A9caire_Albin...

> Art is a system. And programming is a system too. They are different systems.

From a system-centric POV the art world could be considered a system, and the programming world could be considered a system.

Programming is a craft and can therefor be part of an artistic practice as well as many other practices.

What's Art and what isn't is up to each individual and remains generally undefined.

> So, what have you been doing for the last 10 years and why i see only 2026 in your github?

Self-hosted git services are a thing, ya know?

It's a matter of running a for-loop. You'd get faster response times (no query→index translation), but the storage requirements for the indexes would be larger.

What's got this to do with a UPS? Not having a UPS is an external threat on the reliability of the power grid.

Doing a hard shutdown or tripping over power cords seem much likelier local scenarios than any spontaneous combustion of hardware components.

Why not create indexes for multiple languages, as that would also avoid double translation issues (e.g. GER [query] → ENG [index] → GER [document])?

It makes the manifested statements become more realistic, sure, as I doubt any dogmatic approach could even exist for long. But I don't think this warrants anybody to bring out the pitchforks and scream "HYPOCRISY!", though...

This whole thing is a matter of choice, and we shouldn't necessarily conflate the role we take when we consume/use a dependency/tool with the role of crafting own things. I, for one, can apply agency solely on things that offer me means to change them.

"We never use AI. For anything." doesn't mean "We audit every single one of our dependencies, and make sure they never use AI".

Why would you expect a dogmatic approach instead of a more pragmatic one?

> And that logic will last you for years.

A lot of desires that require computation might not be so "logical" in nature, at least not in the automation kind of things.

I use a lot of computing for entertainment purposes and leisure activities, like reading news/ebooks, watching shows/movies, listening to music, gaming, clothing/furniture shopping, going into all kinds of rabbit holes etc. The HN link from GP was such an example.

How could any automation through other physical input help there? Sure, there is vector similarity and recommendation engines, but how could any sensor interpret my aesthetics and my desires to belong/grasp/play/participate?

That sounds exactly like the empty sci-fi promises that current AI companies are betting on.

It's called the Gruen Effect[0], and everything is becoming a product of marketing.

[0]: https://en.wikipedia.org/wiki/Gruen_transfer

If it's turned off for EU customers, it's a pretty clear case that it would be in violation of GDPR, wouldn't it?