nickm12

No, for the reasons given in the sibling comments: you won't want to be locked into a single model for the rest of time and, even if you did, floating point execution order will still cause non-determinism.

I'm not sure what the high-level point of the article is, but I agree with the observation that we (programmers) should generally prefer using AI agents to write correct, efficient programs to do what we want, to have agents do that work.

Not that everything we want an agent to do is easy to express as a program, but we do know what computers are classically good at. If you had to bet on a correct outcome, would you rather an AI model sort 5000 numbers "in its head" or write a program to do the sort and execute that program?

I'd think this is obvious, but I see people professionally inserting AI models in very weird places these days, just to say they are a GenAI adopter.

Thank you. I had to scroll way down to find anyone defending using SI prefixes to mean what they mean everywhere else. A decade ago, I decided to alias "du" to "du --si" and not look back. Entire countries have switched from imperial to metric units. Switching to using base 10 for RAM is really just fine.

I use the phrase "drive-by review" frequently too. As a senior engineer, I worry about doing drive-bys myself. Sometimes my gut tells me something is not quite right about the project, but I just don't know enough about the problem domain or technology/architecture choices to advise definitively.

In this case, I try to question the project owners on their assumptions and whether they have validated them. Usually this line of questioning reveals whether they have "done their homework".

This article resonates with me a lot, but as a senior engineer I would not share it in a big team setting. Even though it's correct, it's too cynical for big team morale. I think it would be worth sharing with peers or managers when discussing whether and how to intervene on a bad project.

Two random anecdotes: when the concept drawing were first shown to the graduate students, someone asked what the swooping walkways above the main corridor were for. The answer they gave was "lightsaber battles".

When we first moved in, there was a seminar room that made some people physically nauseous due to its sloping walls. For a time, they were trying to use masking tape on the walls to make the effect less pronounced. Some of the grad students tried to name it the "vomitorium", but the name never stuck. Fortunately,, once the room had a full compliment of chairs, furniture, and a projector screen the effect seemed to be much less pronounced.

Yes, I think this is what seems to be missed by everything I've read about Gehry in the mainstream. As I said in another post, I worked in the Stata Center at MIT for five years. It was indeed a fun space to walk around in and explore, but it failed to satisfy as a workspace.

I worked in the Stata Center for the first five years and it was just a very poor office building to work in. Even setting aside the leaks and other construction defects, individual working spaces, traffic paths, and communal spaces were not well-separated leading to a lot of distraction. There was also various useless corners due to sharp angles.

I much preferred working in the previous building, CS and AI lab building, NE43. It looked like a punch card from the outside, but had a very nice design with small offices (with closing doors) ringing a common space. The primary downside is the square footage per worker was decadent by today's standard.

Oh wait, we were talking about Frank Gehry, right? His museums looks cool but he should never have been allowed to design an office building.

This is yet another very good critique, but it's long past time that we stop paying attention to Uncle Bob.

Not only are his ideas about how to write software patently bad, but he is willfully obtuse when asked to provide nuance or discuss trade-offs. John Ousterhout's dialog with him, published as "A Philosophy of Software Design vs Clean Code" gave him every opportunity to think critically about his own suggestions and he just doubles down.

https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...

He's just trolling us at this point.

Thanks for taking one for the team. I had zero expectations for Clean Code second edition after reading Uncle Bob's dialogs with John Ousterhout. I thought Ousterhout bent over backwards to give Uncle Bob the benefit of the doubt and discuss the tradeoffs and Bob just dug in on his bizarre dogmatic approaches.

https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...

- Archive: Anything you have a feeling might be useful - Delete: Anything you’re pretty sure would be useless in the future

This has always been my strategy, though some might say I'm closer to "archive almost everything". I still do a lot of deleting, though. Deleted mail tends to fall into the following broad categories:

- security alerts and passcodes - notifications for events happening in a different systems (e.g. Venmo payments, bank alerts, etc.) - receipts for non-durable things like restaurants

I guess I could try to move these more forcefully from email versus phone notifications, but this still is really low priority and it's kind of better to just deal with it in a batch at the end of the day.

That's just Archive with fewer steps

$240/yr is a lot to just have a couple of family mailing lists. Even for creating mailing lists for youth sports teams, local civic orgs, and things like that it's really high.

I agree that the available features can steer the online community culture and behaviors, but it's not determinative. I don't see why online communities should give up useful features just because other communities use them in a way you don't like.

I've been using mailing lists for about 30 years now. In the days before social networks, there was tons of forwarded crap and email chains, such that debunking them was a cottage industry. This behavior eventually moved to Facebook and Twitter which is perhaps why email lists seem more civilized these days, but I don't believe its the features that are driving it.

Sorry, I disagree. The lack of a business model means a lack of competition and a weak market. For years I've been looking to find an email list hosting solution that works for a small family, sports team, friends group, etc. There is next to nothing in this space besides Google Groups. There are a few hosted mailing list solutions, but they have enterprise features and pricing.

What makes them feel like 1970s technology: everyone has to manually manage their own archive and pay storage costs for media files, there is no way to share history (if you want), there is no integrated search, differences in clients mean that people have different experiences of the same message, there are no affordances like reactions that allow people to easily interact with a message without sending an entire separate message.

But maybe I should have said late 80s, early 90s tech. In the 70s, if you were communicating with others on a computer, you were almost certainly using the exact same software on the exact same time-shared system, where at least there was a symmetry of experiences (but no multimedia). The explosion of email clients happened in the 90s, mostly.

Yes! I just bought a dealer-certified three year old Kia Niro with 24k miles for $22k. The current new version of this car has an MSRP more than double that price. There is no world where the difference between these cars is worth $25k. In my head it's more like $10k-$15k max.

Agreed. Any complex mechanical device like a car can be "ridden rough", regardless of whether it is gas or electric. I feel like with gas cars there are a lot more moving parts to get stessed, while electric it's mostly about how the battery was treated. Having bought multiple used cars, including a used EV, it seems like a wash to me.

I read the TeXBook over 25 years ago when I wanted to learn about how mathematics was typeset. It gave me a lifelong appreciation for and love of the art of typography.

The downside is that once you know, you know and you will see lots of bad typography. Though I genuinely think digital typography has continually and gradually improved over the decades. The typography you get "out of the box" is much better than 20 years ago. Also, high dpi displays rock!

Agree these are advantages: Mailing lists are simple - Mailing lists are bandwidth-friendly - Mailing lists interoperate - They're asynchronous - They're portable - They can be freely interconverted - They can be written to media and read from it

Disagree these are advantages: Mailing lists require no special software - They impose minimal security risk - They impose minimal privacy risk - They're push, not pull, so new content just shows up - They scale beautifully - they're relatively free of abuse vectors - They handle threading well

I still use mailing lists, both at work and personally, but they are 1970s technology and it feels like it. We could build mailing lists for this century that keep these advantages and fix what's broken, but there's no business model in it.

> There's an important sense in which you are very wrong here because nothing on the internet is actually hidden. Everyone can see everything

I'm impressed with how confidently you disbelieve in the field of computer security.

I've used a lot of social networking systems over the years based on a lot of technologies. I deeply understand the nostalgia for blogs and RSS—I had a blog for many years and have used an RSS reader continuously since probably 2002. I still enjoy reading blogs to this day.

The problem with blogs, though, is that there is no great solution to limit the visibility to certain audiences. It really limits the types of things you can share. At least with Facebook, you can limit posts to your friends or groups of friends. But even that is not really practical—it's too much effort to have every person curate every other person they know into groups for access control (Remember "circles" on Google Plus? It didn't work).

I think the right model is to allow distributed communities to form organically and then use those communities for sharing permissions. By "distributed communities" I'm thinking of things like email lists, Discord servers, phpbb forums—communities where membership is symmetric and there is a shared sense of who is in the community. Blogs don't have anything like that.

I can relate, but generally if I avoid updating in the first quarter of the release, I don't find it is too difficult to get my Mac back to a happy state. I did try to move to Linux a couple of years ago, but just couldn't. The keyboard, mouse, window system, and app ecosystem were far and away less usable for me and there was nothing I could find to do that would make the machine work as well for me as Mac, despite what Apple is throwing at us.

It's still a talking point. Lattner said in this very interview "at some point people will consider it to be a Python superset, and effectively it will feel just like the best way to do Python in general." Note the hedging phrase, "consider it to be".

Even if the goal is to be just "close enough", It seems as pie-in-the-sky (Py-in-the-sky?) now as it did when Mojo was first announced. CPython has a huge surface area and it seems like if Mojo is going to succeed they are going to want to focus on differentiating features in the ML space and not going feature-for-feature with CPython. I don't know what "close enough" is, but closer than Py2 was to Py3, certainly.

We have different expectations I guess. I think of CLI as applications, even though they aren't "Mac Apps". I don't see what is gained applications putting their files in different places based on how I interact with them.

This piece is arguing against what is often called "over-engineering" or unnecessary abstraction (YAGNI). Over-engineering is a problem in software systems because it generally takes longer to build and it makes the systems unnecessarily more difficult to understand. While a problem, I don't think it is the most important design issue I see in software systems.

The bigger problem I see is lack of abstraction, or systems where the components have too much knowledge of each other. These are fast to build and initially work just as well as the more "heavily engineered" systems. However as the code evolves to meet changing requirements, what happens is that code becomes more complex, either through even more coupling or through ad hoc abstractions that get implemented haphazardly.

It can be really difficult to know where to draw the lines, though. When you are trying to decide between a simpler and more complex option, I think it's worth starting with the simplest thing that could possibly work, but build it in a way that you can change that decision without impacting the rest of the system.

On a tangent, I'm not a fan of Uncle Bob (to put it mildly) but this topic makes me think of his quote "a good architecture allows decisions to be deferred". I would restate it as "a good architecture allows decisions to be changed in isolation".

The hypothetical comparing ChatGPT to a human OpenAI employee is instructive, but we can also compare ChatGPT to a lawnmower sold by a company. We have product safety laws and the ability to regulate products that companies put on the market.

This is the answer. Gruber has and will continue to criticize Apple, but there has generally been very little room for daylight between his values and those of the company (either as expressed in their products or by their leadership). Also, while he doesn't say it, but I suspect that there has long been a feedback loop where his articles defending the company line are well-received internally and have helped him get press access to executives (for his WWDC live show) and preview hardware.

All that said, there has been a marked change since John's "Something Is Rotten in the State of Cupertino". Reading between the lines, it's pretty clear that Apple leadership did not like this article and snubbed him for his liveshow. Since then, there have been many more articles critical of Apple on daringfireball.net.

Put me in the disagree camp. The XDG spec seems like it is for X windowing-based systems, not the Mac, so that's not a reason to adopt. The author asserts what users expect, but without any evidence.

FWIW, it's not what I expect. I used Linux and Solaris extensively between 1995-2005 or so and have been a terminal using Mac user since Mac OS X public beta. My expectation is honestly that CLI programs will do whatever the heck they want and I've never heard of .config. I generally expect both configuration files and application data to reside at the root of my home directory, ideally in a subdirectory if there is more than one file.

If I could choose, I'd prefer for application data (files written by the application for its own use) to go in ~/Library/Application Support, because that's where I expect it to go. For configuration that I would edit by hand, I'm not so sure. Probably would prefer the root of my home directory, where I could at least find it easily without looking it up.

It's been 10 years since Rust 1.0, the first stable version of Rust. It's a perfectly reasonable milestone to use as the birth of Rust as we know it today.