honr

AI does change the equation. It frees a solo developer to focus more on the big picture. BUT... with the current generation of AI agents, I think you are still right. You still need a second (or ideally more; I'd say 5) developer(s) to get enough perspective to have solid plans and roadmaps.

So, while I currently [mostly] agree, I think the / a next generation of agents might take that over a threshold and make solo development close enough to the equivalent of current 2-dev work to meaningfully change the equation. Furthermore I think that does not even need new models; I think current models with better "harness / tooling / system prompting / skills / etc." (whatever you may call the text files describing important procedures), might be able to fill most of that gap.

Obviously work that needs more than 2 devs planning might take even longer to fully solve with 1 dev + multiple agents, if ever.

My current mental model is that humans can very well think about and walk the boundary of problems, while [current] AI agents can fill the inside to some extent. If a problem has inherent "multi-dimensional boundaries", it might be hard for a person to imagine and walk it well to guide the agents. And I think most of the interesting problems fall in this category.

If you still wonder why there are sudden attacks on Mullvad, I "heard" there are Chinese (in addition to the others; dual- / triple- vendoring is key) LLM-based tools to check for swarm origins and campaigns.

Agreed, mostly. To me the effectiveness of window managers is a bellwether of the control aspect. So, IMO, if you compare them on control or on the quality of window managers, you'll get the same result. Linux has ended up with many window managers (effectively catering to various styles and needs), while macos, for example, has a one-size-fits-all approach with no REAL multiple-desktops (Spaces is a joke and a toy). As a result, I can easily manage 50-100 open terminal windows on my linux box, but on macos 5 is too many (and if I use Spaces to fit a few more, I can't get to the terminal I need in less than a second. In linux, even with 100 xterms, I can). So, a macos product manager might probably ask me why I would want 100 terminal windows, to find me some alternative. In linux no one asks me that question, and hence I can have what I want.

Honestly, at fundamental level, it is less of that need being dependent on third parties, and more of not having at least ONE set of consistent libraries (or one big library). To me the real value add of golang's std lib is not that it is developed by the language authored (that is maybe the third or fourth key point). The first one is the existence of one set (or 1.5, heh, if you consider golang.org/x slightly different) of libraries that are polished and hammered to be consistent together (primarily by spending an enormous effort on simplicity, but also on repeated polishes prior to the first notable public release and some thenafter). This is at the core of what I think rust needs right now to break through and penetrate into real C++ and golang circles.

The C++ std lib is no longer terrible. It is really at a usable level these days. Not fun, but totally bearable. The motivation for C++ has never been the quality of the language or the std lib anyways, so it can happily chug along in many places (including the browser I am typing this on).

I disagree about merging existing "done" libraries into a mega library. That can work to some extent, but that approach will not produce something lasting (in the sense that it will remain without the need for changes for a long time). The way to achieve a lasting mega library is by putting all the pieces you need, and constantly working to increase the consistency between them. Somewhat like turning a long winded rambling into a much denser article.

Going from a set of good and working libraries to a large CONSISTENT library would be substantially laborious. Hence the need for someone with deep pockets to take it on. (There are other ways for that to happen but those are rarer).

C++ (the language) and its extreme complexities (each perhaps added for a good reason at the time, and then held together with backward compatibility as glue) reduced itself to gcc and clang. Not the std lib. The std lib is, de facto, removing some of the complexity.

Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.

My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib, and a few domain specific comprehensive libraries. That doesn't even need to affect the existing ecosystem. There can be several parallel ecosystems and each one can be relatively thriving (one doing nodejs style YOLO, one doing enterprise extreme best-practices, one doing efficient embedded or OS level work, etc.). However, apart from the nodejs style community, the rest will benefit [heavily] from a base library that is well designed and NOT subject to change. Even a travesty such as a vibe-cloned golang std lib would be an improvement over the current situation.

I believe by a wide margin the most significant long term problem with rust is lack of a good and comprehensive standard library, or a FEW set of crates that provides a really good set. We are in the age of supply chain risks and I personally know many great engineers who shun languages whose community / library providers don't take this problem with utmost care. At this point in time, rust is being treated like nodejs. That is not fair to rust, but that is the reality of the current situation.

Go, on the other hand took simplicity as a major goal, and while not the most efficient or expressive language out there, that single goal is paying massive dividents.

The good news is, all this means, is that rust can / will be a lot more serious when someone, possibly a big corporation with deep pockets to maintain this until a critical mass has formed, develops and maintains a golang-style standard library. It can be like C++'s in which the initial std lib was crap compared to what it is now. But people ended up using and eventually evolving the language and the std lib together. We are missing that kind of library at the moment.

Cloudtop to run builds, g4 commands, etc., and srcfs / srcfsn to actually write code. (caveat: I have never used neovim, so I don't know if that is different).

When using AI, I often find myself preferring either plain text (no markup whatsoever; just manual / text editor formatting of text blocks) or simple html to markdown, depending on the situation. To the point that I rarely see any point in using markdown for anything. If it is meant for to be a simple text mainly for human consumption, the markups often don't add much clarity (and often bring in an amateurish look, as if the author didn't know how to emphasize using English constructs), in which case plain text feels more pprofessional. If it is meant to be [lightly] processed before being presented to a human, or if it is meant to be processed by a tool / bot / LLM, then HTML is infinitely more straightforward.

Also I often call out my colleagues if they try to put a table in markdown. Markdown is not built for tabular data in most professional settings (i.e., one or two table cell could easily take a whole line of markdown to express). A basic <table><tr><td style="background: red">some number</td></tr></table> goes a long way.

I do get pleasure from typing out the code in some languages (and not in others; hello javascript, java!). Similarly, I love writing text with a calligraphy or fountain pen. However, I can't dedicate too of the much work / business time to whatever is more pleasurable.

So, I "doodle" some text / ideas / planning with a calligraphy pen, and type in some code, occasionally, both mainly for the fun aspects. There are side benefits to both, too. Writing some plans slowly and "beautifully" drags them out and I get to think longer on them, so the sporadic "nice looking plans" are often more well thought. And doing the coding all by myself stops my brain from losing the ability. I was initially in the 100% AI-writes-all-code camp for a while and noticed I am getting notably slow in some personal coding skills. It is too early to treat specs as the new code and old languages as assembly (but I admit we might get there some day).

In other words, I think AI doing 90-99% of the coding, depending on the language verbosity and AI accuracy for the code at hand, is quite reasonable.

Of course it can be used. But it is very buggy (as in missing or not well-though-out behaviors), which is unlike the typical polish Apple human interaction folks deliver. For example switching between Spaces and then between apps and windows and creating a new app window don't work as expected in some combination of steps and for some apps. There are several other "corner" cases that show the features were not laid out in a full design to exhaustively decide the desired behavior in each case. Which is very much like when someone bolts on a feature to a system without fully nail down its interaction with all other adjacent and relevant features.

This might have been the case a couple of years ago, but it is certainly not true any more, if you use AI [even occasionally] to manage some of your default.nix and flake.nix files. I learn by getting AI to edit it (default.nix for example), and then study what it did. It helps.

The quality of the managed / packages software, however, is still a bit subpar compared to Debian and Redhat.

Why would you use that feature? MacOS doesn't REALLY have multiple desktops (Spaces). That is merely a pre-release feature (for 10 years or so, I think). As evidenced by the many critical user journey bugs it has that don't get addressed.

I use both linux (with a decent tiling window manager; the tiling management being the least important part of it) and macos. And certain things are just not possible to do with macos. On linux I can have 300+ open terminal windows AND CAN find the one I need when I need to. On macos 20 (counting in Termianl tabs, which are implemented as windows, underneath) is about the high mark that it gets annoying to work on. On macos, you can't effectively work on multiple projects that use the same software (editor + terminal, for example). You can work with different Applications, though, and that is managed pretty well (better than most linux window managers that I have seen).

Every year or so I try adding a couple of Spaces, and always regret it a couple of hours later, switching back to a single Space (+ a few fullscreen apps).

Nix is not the same as nixos, and in this case the distinction matters. It has to step carefully around Apple's updates. This further highlights the fact Apple lacks the same quality package management as some linux distros. Nixpkgs (on macos), Ports, and Homebrew packages are toys compared to the EFFORT that goes into maintaining Debian and Redhat packages.

In terms of package management SOFTWARE, however, nix (and guix, lix, etc.) are state of the art and work fairly similar in both linux and macos. A deeper integration with the OS would have been nice.

The current market share shows how far you can go with just being a better Java.

If (or when? I haven't checked recently) a decent and well-thought-out LLVM backend emerges for it, ideally with some new underlying complexity seeping through, the market share might expand overnight.

And as for C++, while some complexity is certainly unavoidable, a rigorous complexity control is desperately needed. Ideally, the same way Bell Labs folks did when they initially conceived Go from Algol68 and C and similar (before or after joining Google; I couldn't tell), and Rich Hickey did when he initially designed Clojure. Some people are managing the complexity using style guides and clang-tidy checks. Which is great in that doing so doesn't need lengthy language committee decisions. But that approach hasn't been enough to make code _sufficiently_ safe; every now and then an enterprising engineer or team finds a way to abuse a feature in a way that produces unsafe or unpredictable results. Rust is a bit better and solves a few of the common problems, but sadly the list of potential issues (of using Rust in a codebase at scale; Engineers' faults, not Rust's) is long and growing. My verdict is we need both complex and simple LLVM languages, ideally co-designed to have no interop problems by design, while allowing expressing some logic in the simple parts and some logic in the complex parts. Or better, a 3 tier design would be nearly perfect: expressive config language, glue and research language, and core building blocks language. I think a clojure-style language can be designed to achieve all three.

"I Want to Wash My Car. The Car Wash Is 50 Meters Away. Should I Walk or Drive?"

I found it curious to ask the model to provide its reasoning in that turn, without changing the verdict. Here is one response:

To provide the full picture of the initial reasoning, we have to address the "geospatial" logic of your request. When you asked if you should walk or drive to a car wash 50 meters away, the reasoning relied on a fundamental distinction: The difference between the "Car Wash" (the business) and "Washing the Car" (the action).

Here is the expanded breakdown of that logic:

1. The Location Assumption My reasoning assumed that the car is currently at your home and the professional car wash facility is 50 meters away.

If you drive: You are moving the "object to be cleaned" to the "cleaning tools."

If you walk: You are moving the "cleaner" (you) to the "cleaning tools" to prepare, or you are choosing to bring the "cleaning tools" to the car.

2. The "Walk to Wash" Strategy (Home-Based) The most significant expansion of the "Walk" recommendation is the realization that 50 meters is well within the range of a standard garden hose. Most heavy-duty garden hoses are 15, 25, or 30 meters long. By connecting two hoses, you can reach the car without ever starting the engine. Walking to the car wash facility to buy supplies (or simply realizing how close it is) highlights that you don't actually need to move the car to achieve the goal.

Zero-Motion Cleaning: By walking back and forth with your buckets or hose, the car stays in its spot. You avoid "flash rusting" your brake rotors, which happens almost instantly when you wash a car and then let it sit after a short drive.

3. The "Scout and Prep" Logic If you must use the equipment at the facility (like a high-pressure wand or an automated bay), walking there first is the superior "Logistics" move for the following reasons:

Queue Management: 50 meters is close enough to see the line, but walking allows you to talk to the attendant or check the bay's status. If you drive and there is a 20-minute wait, you are stuck idling your engine (wasting gas and creating heat) or turning it off and on (draining the battery). Walking allows you to timed your "driving" moment perfectly.

The "Dry Interior" Principle: If you walk to the wash to buy your tokens, prep the vacuum, or set up your towels, you are doing the "dirty work" while the car is safely tucked away. Once you finally drive the 50 meters, you do the wash and drive back. This minimizes the time the car spends in a high-moisture, high-chemical environment.

4. The Potential for "Mobile" Service By walking 50 meters to the car wash, you might find that they offer mobile detailing or have "loaner" equipment. In a high-density area, a car wash 50 meters away is practically your neighbor. Walking over to establish a rapport can often lead to a "valet" situation where they come to you, which is the ultimate way to get the car washed without ever sitting in the driver's seat.

----

also noticed a typo and asked it about that:

what does "timed" in `Walking allows you to timed your driving" moment perfectly.` mean?

That is a typo on my part—it should have been "time" (the verb).

That won't change until top-notch, simple (i.e., without 100 transient dependencies) org parsing and formatting libraries for a few key languages (go, javascript / typescript, and python; maybe also C++ and java) become available.

Which is sad because org-mode seems far more versatile than markdown, except for a couple of ergonomic features (e.g., ``` vs #+BEGIN_SRC, and * [x] task vs * DONE task).

Even libraries to parse and format a subset of org-mode would be good enablers.

I went to school in a poor country, and live in the US. The education budget was very low when / where I grew up, and it is pretty hefty where my kids go to school. I occasionally visit their school and volunteer to help. That has given me a good frame for comparison.

The quality of education my kids are getting is pure trash compared to what I receieved.

The problem is not the budget. It is the lack of real teachers, as well as a perpetually experimental curriculum. The "modern" methods that I have seen their teachers practice (which confuse the teachers, too, by the way; the teachers all have said that), are very visibly wrong. So wrong that even I can see all sorts of flaws, despite not having any background in education science. The curriculum is predictably set for failure.

I strongly believe technology, and AI in particular, can be a major enabler in improving education. However, for early education (first 5-6 grades), I think absolute lack of technology (except maybe a big e-ink class whiteboard, or some such) would be far more beneficial. Kids can learn to type very quickly when needed (ideally 6th / 7th grade). They can't learn thinking-while-writing, as quickly. They have to slowly build up that mental muscle. Let them have a few years of building structure and core understanding, then get exposed to tools for doing things faster.

Power conversion efficiency is at best the 3rd or 4th important factor here.

The first factor would be the hodgepodge of wall dongles one needs to own and maintain (plus the cost of buying a dongle for each device that doesn't have one, or multiple of them per device in case you want to charge your phone/laptop/etc in more than one location at home).

The second factor is the "smoothness" of your DC sources. Most of the common LED lamps have a pretty ugly signal shape, and not at all close to a DC flat line. This is mostly unavoidable as AC->Smooth DC conversion is more expensive than AC-> DC + a ton of 120Hz, 240Hz,... on top of it. So, common LED lights tend to opt for cheaper "electronics". People notice the flickery LED lights to various degrees (some get headaches, some outright see the flickers, some claim to be totally oblivious to the difference). The DC "quality" also affects some fairly sensitive electronic devices, so some AC->DC adaptors are fairly sophisticated. A central high quality AC->DC convertor (combined with DC wiring) has better scalability when you need to care about smoothness (it can be a basic quality of life matter for some people).

The third and fourth factors are power discipation and conversion efficiency. They are the same thing, with two remedies: more $ to remedy the inefficiency (which is really small these days, if you go for switching convertors), and plans for heat to discipate properly (devices end up with pretty hot adaptors).

I keep checking Amethyst every couple of years. Still not remotely comparable to i3 or other linux window managers. For one, it's extremely slow. I think it is about two orders of magnitude slower to say, move to another desktop/Space, than most (all I used, really) Xserver window managers.

The "Caveat" on the yabai's README page has been enough to deter me away (or rather, make it strictly impossible for me to try it). And it's not even yabai's fault that Apple has made the window manager (WindowServer) mandatory.

So, no usable window manager here so far, yet.

I use both. Here is my take on it:

1. Mac has shit for a window manager. When I focus and get in the flow, Mac's window manager becomes a massive showstopper for me. My productivity lives and dies by my window manager customizations and shortcuts. Mac's is just a joke when it comes to controling 20+ windows. I sometimes have 100+ editor, terminal, and browser windows. Linux has many window managers up to the task (i3, xmonad, openbox, and countless more). Mac has the default one which you CAN'T change. There are Window Manager "Apps" which use the default window manager's APIs to tell it to, say, move this window to this area. As a result, I haven't found a usable third-party window manager on Mac that can operate at a fraction of the speed of the simplest window managers on linux.

2. Mac's official builtin package manager is a joke. The community's effort to fix it (Homebrew) is halfway between the debian maintainers community and the nodejs community, closer to the latter. I wouldn't say Homebrew is a joke, but it's not really comparable (and fair to compare) to the many human-years that has been poured into QA and patches the Debian community does. Also, you can touch all aspects of the system with apt/dpkg, unlike the like of ports or Homebrew. For people who want more control there is also Arch, and many other distros to pick.

3. Laptop build quality: IMHO Mac doesn't really have a contender here. Every year I try to hard-force myself to buy a non-mac laptop and fail. There is really no one serious enough (or, to be fair, with the same order-of-magnitude of cash and operations and hardware expertise) to pull of the same build quality. An anecdote (but very generalizable): A while back my non-mac (yet, a very well-known brand) laptop's fan died. I got a fan and replaced it. My wife's mac laptop's fan also died about the same time. I replace that one, too. At one point I had both laptop's open on my desk beside each other. I never want to buy a laptop with _visibly_ poor engineering ever again. Guess you have to compare the internals of a few laptops to get my point.

4. Software compatibility: I think this is a very fragmented area, to be fair to all OSes. A lot of vendors only produce on Windows. Some are Win+Mac. Some are Win+Mac+Linux+ChromeOS+Android+iOS. Also a very (yet very significant in some sectors) are Win+Linux, or Linux-only. So, one has to check the availability of the critical software they need. My gut feeling, lacking any better measurement, is that Mac has far more compatible Apps than Linux, especially Apps for the general public (not taylored to a high-tech profession).

5. Appeal: Mac has clearly undergone far better UI/UX design and QA processes than all existing linux DEs. This is very visible to some people (if not to most people), and does change the personal choice of people.

6. Stability and similar problems with Linux: I use both Mac and Linux everyday, and for me Linux and Mac has been about the same in terms of stability (with linux maybe a bit more stable). This is obviously hardware dependent, and linux runs on a vast number of hardwares, so it's not easy (or reasonable) to compare all Mac and all Linux instances. Or at least I don't care about such a comparison. Only the Linux configurations that make sense (well supported, without undocumented hardware blobs, etc.) matter (to me at least).

Overall, I prefer my Linux machines (not just because of software freedoms, but also because Mac is unusable for me when I work on large/serious software projects), but I simply can't live with current batch of Linux laptops either. Maybe in a few years some decent ones show up (purism could get somewhere, or system76, etc). Or maybe Apple finally works to scale up their window managers and package managers to make them suitable for special-cases and make it a bit less frustrating for some of us.

Heh, most of my emacs shortcuts start with ;

Perhaps ironically, mac OS text input boxes are where I use most of the traditional emacs C-/M- keybindings these days.

It is certainly true that languages designed for simplicity (such as go, clojure, and to some extent python) exhibit far less friction when composed in minimal editors, than [overly?] verbose/complicated languages such as Java.

However, I vehemently disagree with some of your (implied?) points. In particular, some functions offered by IDEs and other codebase management tools are almost equally useful for both simple and complicated languages. For example refactoring tools, or if we really look at the stem, code-base analysis tools that 1. parse the language, and, 2. have APIs for modifications, are some of the "power tools" that could be useful for virtually any programmer.

As an IDE-averse person, I find myself reaching out for the simpler languages far more often, and do actively dislike high-ceremony systems. All the while, I am painfully aware of the limitations of using only a [good] text editor. My main alternative (to mainstream IDEs) is to context-switch between pure code-writing episodes and refactoring/analysis/etc. periods (using other tools, most on the command line or with output to a web-browser).

Also regarding your comparison between written programs and mathematics: I think that comparison is relevant ONLY for low-churn fundamental code (such as core libraries, or generic utility libraries) and rather poor in a LOT of "business logic"/"presentation layer" code. I myself play code-golf and run several _mental_ redesigns/refactorings when working on code that should be solid and not subject to frequent revisions. In such cases, yes, the code should be readable, well designed, and simple to follow (clarity slightly preferred over performance for the core). Nearly formal and exhibiting formal/math-like traits. On the other hand, "business logic" code is inherently unstable and could require numerous revisions purely due to external requirements. Such code usually shouldn't be optimized for tight simplicity. "the first thing that came to my mind"-level clarity with comments can suffice. Common IDEs do help with the latter type of code (while, I think, not much with the former).

Beside serious analysis and modification tools, there is an extra set of features provided by many IDEs, such as lookups (lookup function/library/etc. initiated while looking at code), autocompletion (based on parsed code or just string matching), etc. These are certainly nice, but I don't think they change the landscape much between IDEs and plain text editors (or rather, editor-and-a-documentation-lookup-web–browser-on-the-side).

So, for me, IDEs are certainly valuable even if I don't use them frequently. In a more ideal setup, I would write my code in my preferred editor without much hand-holding and with just the simplest of IDE-like features. And then, separately, do codebase "polishing" with dedicated analysis tools that may or may not look like conventional IDEs.

I'm not sure about the genetics of it (none of my family members seem to agree with me), but I also perform computer tasks far better in a dim light. A friend of me, who is also a night-owl, has the theory that when we get exposed to daylight, our cavemen heritage's natural reaction is to feel like going hunting/food gathering. While I don't buy the argument verbatim, I feel more like doing outdoor/physical activities on sunny days.

I kept seeing the following problem with several different LED lights we were installing until I found one that was better: Take your phone and take a video of the lights when on (normal framerate should be enough, try slow-motion for further investing). Most lights I got from the local hardware store were flickering quite visibly. And I'm pretty sure it's a design insufficiency of the adaptor electronics attached to it, not the LEDs themselves. If I were to guess I'd say most of them probably go the simple path of cutting off the negative half of the AC cycle and feeding the rest directly, without a decent low-pass filter to the LEDs.

What worked reasonably well for me, was getting a normal DC power supply and a few LED strips (with fairly dense and higher power LEDs) and installed that in a room. That light feels pretty satisfying to me.

All that being said, I don't like anything even remotely close to daylight level ambience when I am working on a computer screen; the custom lighting I set up is for other living areas.

Not really surprising to some of us. Definers Public Affairs and a couple of other firms have been working hard for it. At some point the hacker news community might become more immune to paid-for opinion shaping, but that time is not now.

So, I couldn't understand what "exposed" means in that article. Was any user's data obtained by someone not authorized to do so, or merely access to the data was possible?

Perhaps a correction, if we are talking about the phrase "don't be evil", literally, I can see it on: https://abc.xyz/investor/other/google-code-of-conduct.html

Perhaps "erased" is not quite accurate.

Compared to tilting my head to the second monitor, it is measurably faster to type ^3 (Control + 3) to switch to the space/virtual-desktop where my email window is open (~1.5sec vs ~0.7sec).

If one has to Alt+Tab or Command+Tab through programs, yes, that would suck the life out of productivity.

The only real benefit larger screen spaces (larger than a ~30 inch monitor) provide me with, are when I need about 4-6 open windows (maximized vertically) to switch between when dealing with large merges/patches. I haven't experienced any practical benefits beyond two ~30inch monitors.

Please kindly cut the BS and use the link and title of the study. The magazine it's published in seems to be the second highest impact magazine of its field (sorry I haven't done research in cellular biology to know the magazine well). So, the study is probably reasonable. The click-baity artistic interpretation of the study is what tarnishes this and numerous other works.

"Dietary fat, but not protein or carbohydrate, regulates energy intake and causes adiposity in mice."

https://www.sciencedirect.com/science/article/pii/S155041311...