renerick (u/renerick)

renerick commented on AI URI Scheme – Internet-Draft ietf.org/archive/id/draft... · Posted by u/enz

renerick · 3 months ago

This document defines a scheme for "AI-adressable" resources without much care about definition of "AI-addressesable" or even the properties of such resources, that require a dedicated protocol.

I get very strong "E = mc^2 + AI" vibes from it, just shoehorning the coveted letters everywhere

renerick commented on Thin desires are eating life joanwestenberg.com/thin-d... · Posted by u/mitchbob

xpe · 3 months ago

  > A thick desire is one that changes you in the process of pursuing it.
  >
  > A thin desire is one that doesn't.
  >
  > ...
  >
  > The person who checks their notifications is [a thin desire],
  > afterward, exactly the same person who wanted to check their
  > notifications five minutes ago.

[I added the brackets]

The author, I think, would label the desire for sugary drinks as a thin desire. However, that desire tends towards unfavorable consequences: mood swings, poor dental hygiene, weight gain. Thus it undermines one's body. This "changes you" -- for the worse, yielding a contradiction. If the preceding logical analysis is sound, the article's terms or argument are flawed.

renerick · 3 months ago

You said it yourself - "sugary drinks... tend towards unfavorable consequences". The change happens as the outcome of the desire, not "in the process of the pursuing it".

renerick commented on A WebGL game where you deliver messages on a tiny planet messenger.abeto.co/... · Posted by u/thecupisblue

renerick · 6 months ago

After listening to a certain science fiction podcast and playing through a certain space puzzle game, I think I've got a bit of a soft spot for tiny worlds, especially a world this charming! Good work

renerick commented on Typst: A Possible LaTeX Replacement lwn.net/Articles/1037577/... · Posted by u/pykello

renerick · 6 months ago

Typst is fantastic and I recommend to dive into it to see how much value it offers. To me personally, the biggest strength is the ergonomics of both the tooling and the language, and how ergonomics persist even between documents of various complexity. Writing a paper in LaTeX is nice, but making something like a CV takes some patience. Meanwhile, in typst it was quick to get started and go all the way to building resumes, character sheets, and I know of at least one occurrence of implementing symbolic math in typst language. It's not without quirks, but still, very solid alternative

renerick commented on Rules for creating good-looking user interfaces weberdominik.com/blog/rul... · Posted by u/domysee

renerick · 6 months ago

I would argue that the second screenshot with redesigned Lighthouse is slightly worse that the "old" design

- the vertical ruler between the sidebar and the content is gone, making page structure less pronounced - the redesigned dropdown menu has no borders or shadows and blends with the primary background - the redesigned dropdown menu lost the little dot which highlighted currently selected option, replacing it with a folder icon, but now it's not useful, because it's the same folder icon for each option - the old design had really nice and noticeable "Add URL" button. I suppose, it was removed in favor of the "plus" button in the sidebar, but it's not nearly as noticeable and without the label it's not clear what it actually does

Sure, the issues in the old version are valid, but I think the redesign introduced more severe usability issues instead of mostly aesthetic issues

renerick commented on What's New in C# 14: Null-Conditional Assignments blog.ivankahl.com/csharp-... · Posted by u/ivankahl

estimator7292 · 6 months ago

I don't really get this obsessive insistence of purging the language of null checks. (And "if(x is not null)" is not an improvement of any kind)

It feels like Microsoft just wants C# to be Python or whatever and the language is losing its value and identity. It's becoming bland, messy, and complicated for all the same reasons they keep increasing padding between UI elements. It's very "me too" and I'm becoming less and less interested in what I used to consider my native language.

I used to write any and all little throwaway programs and utilities in C#, but it just keeps getting more and more fussy. Like Python, or maybe java. Nowadays I reach for C++. It's more complicated, but at least it's stable and not trying to rip itself apart.

renerick · 6 months ago

> wants C# to be Python or whatever

Oh, how happy would I be if Python had a sliver of C# features. There's nothing like null-conditionals in Python, and there are many times I miss them

renerick commented on Why you should choose HTMX for your next web-based side project (2024) hamy.xyz/blog/2024-02_htm... · Posted by u/kugurerdem

uh_uh · 8 months ago

It cannot scale because it doesn't have a solution for reusable components. That's why I have abandoned it. Frameworks like React solve this in a much saner way.

renerick · 8 months ago

Reusable components are prerogative of the templating system, such as React, or Vue, or server side templates that the framework of your choice uses. Htmx works with already rendered HTML fragments from the back end and doesn't do templating on its own, so there's simply no room for it to "solve" reusable components

renerick commented on Most RESTful APIs aren't really RESTful florian-kraemer.net//soft... · Posted by u/BerislavLopac

renerick · 8 months ago

Htmx essays have already been mentioned, so here are my thoughts on the matter. I feel like to have a productive discussion of REST and HATEOAS, we must first agree on the basics. Repeating my own comment from a couple of weeks ago, H stands for hypermedia, and hypermedia is a type of media, that uses common format for representing some server-driven state and embedding hypermedia controls which are presented by back-end agnostic hypermedia client to a user for discoverability and interaction.

As such, JSON driven APIs can't be REST, since there is no common format for representing hypermedia controls, which means that there's no way to implement hypermedia client which can present those controls to the user and facilitate interactions. Is there such implmentation? Yes, HTML is the hypermedia, <input>s and <button>s are controls and browsers are the clients. REST and HATEOAS is designed for the humans, and trying to somehow combine it with machine-to-machine interaction results in awkward implementations, blurry definitions and overcomplication.

Richardson maturity model is a clear indication of those problems, I see it as an admission of "well, there isn't much practicality in doing proper REST for machine-to-machine comms, but that's fine, you can only do some parts of it and it's still counts". I'm not saying we shouldn't use its ideas, resource-based URLs are nice, using feature of HTTP is reasonable, but under the name REST it leads to constant arguments between the "dissertation" crowd and "the industry has moved on" crowd. The worst/best part is both those crowds are totally right and this argument will continue for as long as we use HTTP

renerick · 8 months ago

I felt the need to clarify this point:

> As such, JSON driven APIs can't be REST

I made it sound like JSON APIs can't be REST in principle, which is of course not true. If someone were to create hypermedia control specification for JSON and implement hypermedia client for it, it would of course would match the definition. But since we don't have such specification and compliant client at this time, we can't do REST as it is defined

renerick commented on Most RESTful APIs aren't really RESTful florian-kraemer.net//soft... · Posted by u/BerislavLopac

renerick · 8 months ago

Htmx essays have already been mentioned, so here are my thoughts on the matter. I feel like to have a productive discussion of REST and HATEOAS, we must first agree on the basics. Repeating my own comment from a couple of weeks ago, H stands for hypermedia, and hypermedia is a type of media, that uses common format for representing some server-driven state and embedding hypermedia controls which are presented by back-end agnostic hypermedia client to a user for discoverability and interaction.

As such, JSON driven APIs can't be REST, since there is no common format for representing hypermedia controls, which means that there's no way to implement hypermedia client which can present those controls to the user and facilitate interactions. Is there such implmentation? Yes, HTML is the hypermedia, <input>s and <button>s are controls and browsers are the clients. REST and HATEOAS is designed for the humans, and trying to somehow combine it with machine-to-machine interaction results in awkward implementations, blurry definitions and overcomplication.

Richardson maturity model is a clear indication of those problems, I see it as an admission of "well, there isn't much practicality in doing proper REST for machine-to-machine comms, but that's fine, you can only do some parts of it and it's still counts". I'm not saying we shouldn't use its ideas, resource-based URLs are nice, using feature of HTTP is reasonable, but under the name REST it leads to constant arguments between the "dissertation" crowd and "the industry has moved on" crowd. The worst/best part is both those crowds are totally right and this argument will continue for as long as we use HTTP

renerick commented on When Figma starts designing us designsystems.internation... · Posted by u/bravomartin

renerick · 8 months ago

It's not like Figma forces to use those features, right? And also, hot take, "limits the possible expressions" is a good thing for application design. Application is not art, first and foremost it must solve user's use case, be accessible, discoverable, ergonomic and practical to implement. Aesthetics must serve and complement those purposes, not be the focus of the design