agarren

Fastmail allows for aliasing too - username@domain.tld -> bank@username.domain.tld, retailer@username.domain.tld, etc. Pretty convenient. I use that feature pretty often and I can only recall one instance which seemed to indicate my address was sold to spammers. It’s more useful for organizing incoming mail, like plus-aliasing in gmail.

Software is hard. AI can radically simplify this by writing the code for you, but that comes at a cost. If you don’t understand what was written, or you only understand it at a superficial level, maintenance is going to be a nightmare. It isn’t uncommon to come back to code you wrote yourself, say, 20 days ago, and need to reacquaint yourself. Extend that to AI.

I’d argue that relying on a tool like cursor to bang out whole routines and types, just using it as “advanced intellisense”, takes away from you truly understanding the solution you’re putting together. It’s fantastic if they make you more productive in the short term, but in the long term, if the generated code is convoluted, difficult to revisit, that’s where you (or a future maintainer like OP) are going to kill time.

The go spec today is ~130 pages [0]. Like golang’s Stalin, its spec remarkably approachable. The latest Java spec is ~800 [1], also very accessible, but clearly there’s more complexity there.

You have to admit, there’s something appealing about being able to read the entire spec for a popular, performant, production language over a lunch break. You don’t need to read and/or master a language’s specification in order to use it. But at 130 pages, you can.

[0] https://go.dev/ref/spec [1] https://docs.oracle.com/javase/specs/jls/se23/jls23.pdf

Relying on composition rather than inheritance often feels much more natural in my experience. C, Basic, Pascal, etc. are all missing inheritance and generics, are they similarly unorthodox and difficult?

Java-style OO has a place, but it’s not always a perfect fit. Java, C#, and arguably C++ have taken a kitchen-sink and grafted any and all constructs found in other languages so long as they look remotely useful. The result often is useful, but it also results in a more complex language.

While Go isn’t a perfect language, nor is it a great language, I /have/ found it to be a productive language in ways that Java, python, ruby, etc. are not. I attribute this productivity boost to the simplicity of the language (if not the runtime) and to the conservative approach taken to add new features.

I agree, but it doesn’t change the fact in my mind that despite golang’s nulls, I’ve found it to be a ridiculously productive language to work with in a lot of cases. I’d credit that to the simplicity of the language (if not the runtime), and, it least from that perspective, it’s something Golang shares with F#. F# has the obvious advantage of a significantly better type system and the disadvantage of not sharing the more familiar Algol/c syntax.

Records, tuples, pattern matching, immutability, error handling with Result<‘a>, distaste for nulls, it’s got everything that Microsoft is trying to shoehorn into C# today, without all the baggage that C# brings with it. It seems like F# (fortunately) does have many reasons /to/ change.

I was hoping to see this one - I was just about to post before seeing your comment. It’s not a long book, but it definitely sticks with you.

I think Murakami’s books are a great suggestion. Magical realism, nowhere near sci-fi, but very easy to slip into. However, 1Q84 feels a bit like a heavy recommendation even if you’re a Murakami fan. It’s a bit more of a commitment and I think it helps if you’re familiar with his other stories before diving into it. I’d say try Hardboiled Wonderland first - I thought it stepped away from some of his recurring themes but still a good example of his style. Also a quicker read. He has a few anthologies might be good intros as well - I read two, Dance, Dance, Dance and The Elephant Also Vanishes, but I think he’s got some others.

Along the lines of magical realism, Kurt Vonnegut seems like a great recommendation too. His books incorporate a bit more sci-fi - Galapagos, Cat’s Cradle, Sirens of Titan, slaughterhouse five, …

I’ve had a Breville Barista Express model for years and it’s been perfect. Daily use (4-8 doubles), easy to clean, very consistent shots. I’m definitely a fan.

I enjoyed Player of Games and it was a good second book for me after Consider Phlebas. I’ve heard a lot of good things about Use of Weapons, but I haven’t been able to get into it after starting and restarting a couple times.

The excellent “Fall of Civilizations” podcast covers this well, too:

https://www.youtube.com/watch?v=nCyzrie_les&list=PLR7yrLMHm1...

Takeaway: Jared Diamond’s Easter Island collapse theory seem remarkably out of touch.

Same - it seems like a decent, small, example of using gtk4 bindings in rust. These kinds of projects are great particularly for anyone comfortable in C and building up fluency in rust.

We're going to disagree, but respectfully, thank you for the discussion.

> This is exactly the confusion caused due to mismatched terminology. In the explanation the "client" is a browser. But obviously the browser isn't an active participant in the exchange.

The browser is also understood as a client in other similar exchanges [0]. There shouldn't be much confusion on the term, at least from a developer perspective.

> The actual client of the banking service is the human looking at the browser.

I don't see it this way. The article is clear about what the term "client" means (e.g., "a proper hypermedia client...", "...the client would render this new HTML...", "...the client must know how to interpret the status field...")

It's also clear from Fielding's thesis itself, referenced in the article, what a "client" represents in its description of REST as a "client-server architecture" with hypermedia as a "client-server constraint" [1].

There is confusion about REST as a term. I don't believe it's due to mismatched terminology or a misunderstanding of the term "client" in the context of REST as a network/web architecture.

> The human knows how to react because they know the English word "deposits" and can continue this game of adventure by interpreting whatever comes back, again based on English labels.

The user of a (web) client isn't relevant in this case, nor is it how the user interprets what comes back. The point is that the (web) client can interpret a hypermedia response without any additional knowledge. The (web) client can make any additional actions available to the user without further interpreting the response as it would with the JSON version.

> Now consider how you'd write a script for a computer to use this "API" in automated fashion.

Now, your script is the client, not the browser, and your script is responsible for parsing the relevant data, following links, etc. How it works with RESTful responses and payloads is entirely up to your script. That said, it seems similar to a JSON response, you'll parse out the bits you care about and proceed accordingly.

> ...The area of controversy is how computers should talk to each other. Another way of saying this is that the concept of "self-describing" data is a handwave that is doing a huge amount of work here.

I disagree, but I can see where you're coming from.

Machine-to-machine communication using hypermedia rather than JSON _still_ strikes me as "self-describing" in the sense that being able to locate, navigate, and act on the resources that hypermedia represents is what a "proper hypermedia client" is designed to do. You can still access the API programmatically, but now you have less parsing to do, and things like navigation and resource manipulation come for free. By that I mean there is no need for a dedicated API client that solely speaks the JSON-RPC dialect of the particular API you are accessing. (I'm thinking of "RESTful" API clients I've recently had to work with in one way or another: Box, BusinessCentral, Azure, DocuSign, etc.)

I don't interpret "self-describing data" in the context of a network architecture to mean that the (web) client has attained enlightenment and suddenly knows what deposits and withdrawals are. There shouldn't be too much confusion on that point, even with the most superficial reading. Fielding describes "self-descriptive messages" as simply a RESTful constraint - not magic. You (through a [web] client) ask for deposits, and you receive a response containing details about a deposit and/or ways to manipulate those data further. How the user interprets the message, what they do with it, isn't interesting. What is interesting is that user will work with the resources through a web client: a RESTful web client can interact with a RESTful resource without additional "out-of-band" knowledge in the form of, say, JSON parsing and buckets of javascript imposing some RPC logic.

[0] https://datatracker.ietf.org/doc/html/rfc6749#section-1.1

[1] https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...

Can you elaborate on what you mean by "an English-speaking human is the client"? It seems to me that if the hypertext response in the example referenced "deposits" in Arabic, Swahili, English, or Japanese, it'd all be the same to the client.

(fta) > The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available.

> The client would render this new HTML, totally unaware of what “overdraft” means or, indeed, even what a bank account is.

So the client doesn't understand what a deposit is, but it doesn't have to. The response provides actions that the client knows how to incorporate and navigate. The alternative being a JSON response that is completely opaque - requiring additional parsing, explicit interpretation, and templating/interpolation, and DOM insertion before it's useful.

A RESTful web client speaks hypertext. JSON-RPC is useful, but is not RESTful in the original sense of the word.

If I understand you right, this seems like a very course-grained way to track changes. You can record that a change was made, but not the specific change. It seems like it'd help facilitate something like, say, an etag, but I don't think could get any auditable data using this alone, could you? Keeping track of added/deleted hashes would probably be best handled by a trigger, unless you really want that in your app code, so this seems a lot like an audit trigger, with very little audit data. Have I misunderstood?

I’m surprised that Sopranos made the transcendent finale list, and equally surprised that Six Feet Under didn’t make it (and isn’t even in the review.) Six Feet Under wrapped everything up so perfectly. The Sopranos, as much as I enjoyed it, did not have a finale that lived up to the show.

There was a similar post a week or two back, and many of the responses mentioned scratchapixel [0]. It seems like a solid recommendation, and I got lost in a couple of the links.

[0] https://www.scratchapixel.com/

I didn’t realize it until looking at it just a moment ago, but Auth0 is an Okta subsidiary. They don’t have a stellar record by themselves [0]. I guess that leaves Amazon? That’s not super encouraging.

[0] https://www.bleepingcomputer.com/news/security/auth0-warns-t...

I’m a big fan of LunarVim, but handling large files out-of-the-box is not a great experience. Observed in both lvim, and neovim with my own config. I’ve found myself leaning on helix in those cases - quicker than screwing with either config, or running vim -u NONE.

LunarVim is my daily driver, but Helix is screaming fast compared to it in many cases.

I’ve heard similar arguments made pretty regularly for almonds and especially alfalfa [0] grown in California or Arizona, and exported to Saudi Arabia. It seems legit to me.

[0] https://azpbs.org/horizon/2022/06/saudi-water-deal-threateni...

I see the following in the English kindle version - seems like it’s the same in spirit:

“We’re humanitarian and noble, we’ve no intention of subjugating other races, we only want to impart our values to them and in return, to appropriate their heritage. We see ourselves as Knights of the Holy Contact. That’s another falsity. We’re not searching for anything except people. We don’t need other worlds. We need mirrors. We don’t know what to do with other worlds. One world is enough, even there we feel stifled. We desire to find our own idealized image; they’re supposed to be globes, civilizations more perfect than ours; in other worlds we expect to find the image of our own primitive past.”

I mostly agree. I enjoy my 40” 4k monitors, but I’ve found that sometimes constraining myself to a laptop display can improve my focus. However, laptop keyboards, even those on macs and thinkpads, are poorly suited for extended use I think. The author is using an external keyboard, and that makes the setup much more usable in my opinion.

They’re obviously more expensive to hire rather than less exciting. Native cross-platform development for a medium-to-large app is a hell of an investment. On going maintenance and dealing with platform upgrades is costly. Probably super impractical more often than not. I don’t see it boiling down simply to “developer experience”, but I don’t completely disagree on that point.

Instead, you leverage what you already have - any modern product is already going to have a web interface. The idea of packaging that interface into a self-contained desktop application with little to no additional effort is just too appealing. Sure, everybody else screws it up when attempting this route, and performance becomes a huge problem, but surely your team will do it right. And besides, webdevs are a dime a dozen compared to C++ guys (and fluent on two or three platforms? Good luck. You’ll pay through the nose the get them and more to keep them.)

Amen. Searching chat history is a uniquely horrible experience. I’d like to search for a word or phrase and see not just the single chat response it appears in, but some context around it. As it stands I’ve found myself searching for a phrase, noting the date on which it occurred, then finding the chat/discussion and scrolling up to that date.

Not the parent, but I use teams in macOS. I wouldn’t call it fast, but I also haven’t experienced the kind of horrible performance other people apparently have.

Video playback and taking calls on a second, larger (40” 4k) display, have improved slightly but are still bad enough that I’d rather move the app to the laptop’s display (32gb mbp mid-2020)

I do think it’s a second-rate app compared to most of Microsoft’s usual offerings - OneNote being a notable exception. Other than the video item above, I’ve found overall performance to be adequate and not remarkable one way or the other.

An op-ed piece from the NY Times? Not what I would consider an authoritative source. The author says caste discrimination is illegal, but goes onto suggest that other than people avoiding discussing the topic, and aside from a few high profile and moderately successful social initiatives, it’s still very much a thing. The piece doesn’t quite support your assertion, e.g.:

> As India transforms, one might expect caste to dissolve and disappear, but that is not happening. Instead, caste is making its presence felt in ways similar to race in modern America: less important now in jobs and education, but vibrantly alive when it comes to two significant societal markers — marriage and politics…

> Inter-caste marriages in India are on the rise but still tend to be the province of the liberal few. For much of the country, with its penchant for arranged marriages and close family ties, caste is still a primary determinant in choosing a spouse…

…and a bit more. Why do you believe caste discrimination isn’t real? That seems like a strong stance.

BBC reporting on the spaghetti harvest.

https://www.youtube.com/watch?v=tVo_wkxH9dU

It’s a family affair in Switzerland, unlike “large spaghetti plantations” in Italy.