Latest Posts (8 found)
tonsky.me 1 weeks ago

It’s hard to justify Tahoe icons

I was reading Macintosh Human Interface Guidelines from 1992 and found this nice illustration: accompanied by explanation: Fast forward to 2025. Apple releases macOS Tahoe. Main attraction? Adding unpleasant, distracting, illegible, messy, cluttered, confusing, frustrating icons (their words, not mine!) to every menu item: It’s bad. But why exactly is it bad? Let’s delve into it! Disclaimer: screenshots are a mix from macOS 26.1 and 26.2, taken from stock Apple apps only that come pre-installed with the system. No system settings were modified. The main function of an icon is to help you find what you are looking for faster. Perhaps counter-intuitively, adding an icon to everything is exactly the wrong thing to do. To stand out, things need to be different. But if everything has an icon, nothing stands out. The same applies to color: black-and-white icons look clean, but they don’t help you find things faster! Microsoft used to know this: Look how much faster you can find Save or Share in the right variant: It also looks cleaner. Less cluttered. A colored version would be even better (clearer separation of text from icon, faster to find): I know you won’t like how it looks. I don’t like it either. These icons are hard to work with. You’ll have to actually design for color to look nice. But the principle stands: it is way easier to use. If you want icons to work, they need to be consistent . I need to be able to learn what to look for. For example, I see a “Cut” command and next to it. Okay, I think. Next time I’m looking for “Cut,” I might save some time and start looking for instead. How is Tahoe doing on that front? I present to you: Fifty Shades of “New”: I even collected them all together, so the absurdity of the situation is more obvious. Granted, some of them are different operations, so they have different icons. I guess creating a smart folder is different from creating a journal entry. But this? There is no excuse. Same deal with open: Yes. One of them is a checkmark. And they can’t even agree on the direction of an arrow! Find (which is sometimes called Search, and sometimes Filter): Delete (from Cut-Copy-Paste-Delete fame): Minimize window. These are not some obscure, unique operations. These are OS basics, these are foundational. Every app has them, and they are always in the same place. They shouldn’t look different! Icons are also used in toolbars. Conceptually, operations in a toolbar are identical to operations called through the menu, and thus should use the same icons. That’s the simplest case to implement: inside the same app, often on the same screen. How hard can it be to stay consistent? Photos: same and mismatch, but reversed ¯\_(ツ)_/¯ Maps and others often use different symbols for zoom: Another cardinal sin is to use the same icon for different actions. Imagine: I have learned that means “New”: Then I open an app and see . “Cool”, I think, “I already know what it means”: You’d think: okay, means quick look: Sometimes, sure. Some other times, means “Show completed”: Sometimes is “Import”: Sometimes is “Updates”: Same as with consistency, icon reuse doesn’t only happen between apps. Sometimes you see in a toolbar: Then go to the menu in the same app and see means something else: Sometimes identical icons meet in the same menu. Sometimes next to each other. Sometimes they put an entire barrage of identical icons in a row: This doesn’t help anyone. No user will find a menu item faster or will understand the function better if all icons are the same. The worst case of icon reuse so far has been the Photos app: It feels like the person tasked with choosing a unique icon for every menu item just ran out of ideas. Understandable. When looking at icons, we usually allow for slight differences in execution. That lets us, for example, understand that these technically different road signs mean the same thing: Same applies for icons: if you draw an arrow going out of the box in one place and also an arrow and the box but at a slightly different angle, or with different stroke width, or make one filled, we will understand them as meaning the same thing. Like, is supposed to mean something else from ? Come on! Or two-letter As that only slightly differ in the font size: A pencil is “Rename” but a slightly thicker pencil is “Highlight”? Arrows that use different diagonals? Three dots occupying ⅔ of space vs three dots occupying everything. Seriously? Slightly darker dots? The sheet of paper that changes meaning depending on if its corner is folded or if there are lines inside? But the final boss are arrows. They are all different: Supposedly, a user must become an expert at noticing how squished the circle is, if it starts top to right or bottom to right, and how far the arrow’s end goes. Do I care? Honestly, no. I could’ve given it a shot, maybe, if Apple applied these consistently. But Apple considers and to mean the same thing in one place, and expects me to notice minute details like this in another? Sorry, I can’t trust you. Not after everything I’ve seen. Icons are supposed to be easily recognizable from a distance. Every icon designer knows: small details are no-go. You can have them sometimes, maybe, for aesthetic purposes, but you can’t rely on them. And icons in Tahoe menus are tiny . Most of them fit in a 12×12 pixel square (actual resolution is 24×24 because of Retina), and because many of them are not square, one dimension is usually even less than 12. It’s not a lot of space to work with! Even Windows 95 had 16×16 icons. If we take the typical DPI of that era at 72 dots per inch, we get a physical icon size of 0.22 inches (5.6 mm). On a modern MacBook Pro with 254 DPI, Tahoe’s 24×24 icons are 0.09 inches (2.4 mm). Sure, 24 is bigger than 16, but in reality, these icons’ area is 4 times as small! So when I see this: I struggle. I can tell they are different. But I definitely struggle to tell what’s being drawn. Even zoomed in 20×, it’s still a mess: Or here. These are three different icons: Am I supposed to tell plus sign from sparkle here? Some of these lines are half the pixel thicker than the other lines, and that’s supposed to be the main point: Is this supposed to be an arrow? A paintbrush? Look, a tiny camera. It even got an even tinier viewfinder, which you can almost see if you zoom in 20×: Or here. There is a box, inside that box is a circle, and inside it is a tiny letter. with a total height of 2 pixels: Don’t see it? I don’t. But it’s there... And this is a window! It even has traffic lights! How adorable: Remember: these are retina pixels, ¼ of a real pixel. Steve Jobs himself claimed they were invisible. It turns out there’s a magic number right around 300 pixels per inch, that when you hold something around to 10 to 12 inches away from your eyes, is the limit of the human retina to differentiate the pixels. And yet, Tahoe icons rely on you being able to see them. When you have so little space to work with, every pixel matters. You can make a good icon, but you have to choose your pixels very carefully. For Tahoe icons, Apple decided to use vector fonts instead of good old-fashioned bitmaps. It saves Apple resources—draw once, use everywhere. Any size, any display resolution, any font width. But there’re downsides: fonts are hard to position vertically, their size doesn’t map directly to pixels , stroke width doesn’t map 1-to-1 to pixel grid, etc. So, they work everywhere, but they also look blurry and mediocre everywhere: They certainly start to work better once you give them more pixels. or make graphics simpler. But the combination of small details and tiny icon size is deadly. So, until Apple releases MacBooks with 380+ DPI, unfortunately, we still have to care about the pixel grid. Icons might serve another function: to help users understand the meaning of the command. For example, once you know the context (move window), these icons explain what’s going on faster than words: But for this to work, the user must understand what’s drawn on the icon. It must be a familiar object with a clear translation to computer action (like Trash can → Delete), a widely used symbol, or an easy-to-understand diagram. HIG: A rookie mistake would be to misrepresent the object. For example, this is how selection looks like: But its icon looks like this: Honestly, I’ve been writing this essay for a week, and I still have zero ideas why it looks like that. There’s an object that looks like this, but it’s a text block in Freeform/Preview: It’s called in SF Symbols: Why did it become a metaphor for “Select all”? My best guess is it’s a mistake. Another place uses text selection from iOS as a metaphor. On a Mac! Some concepts have obvious or well-established metaphors. In that case, it’s a mistake not to use them. For example, bookmarks: . Apple, for some reason, went with a book: Sometimes you already have an interface element and can use it for an icon. However, try not to confuse your users. Dots in a rectangle look like password input, not permissions: Icon here says “Check” but the action is “Uncheck”. Terrible mistake: icon doesn’t help, it actively confuses the user. It’s also tempting to construct a two-level icon: an object and some sort of indicator. Like, a checkbox and a cross, meaning “Delete checkbox”: Or a user and a checkmark, like “Check the user”: Unfortunately, constructs like this rarely work. Users don’t build sentences from building blocks you provide; they have no desire to solve these puzzles. Finding metaphors is hard. Nouns are easier than verbs, and menu items are mostly verbs. How does open look? Like an arrow pointing to the top right? Why? I’m not saying there’s an obvious metaphor for “Open” Apple missed. There isn’t. But that’s the point: if you can’t find a good metaphor, using no icon is better than using a bad, confusing, or nonsensical icon. There’s a game I like to play to test the quality of the metaphor. Remove the labels and try to guess the meaning. Give it a try: It’s delusional to think that there’s a good icon for every action if you think hard enough. There isn’t. It’s a lost battle from the start. No amount of money or “management decisions” is going to change that. The problems are 100% self-inflicted. All this being said, I gotta give Apple credit where credit is due. When they are good at choosing metaphors, they are good: A special case of a confusing metaphor is using different metaphors for actions that are direct opposites of one another. Like Undo/Redo, Open/Close, Left/Right. It’s good when their icons use the same metaphor: Because it saves you time and cognitive resources. Learn one, get another one for free. Because of that, it’s a mistake not to use common metaphors for related actions: Another mistake is to create symmetry where there is none. “Back” and “See all”? Some menus in Tahoe make both mistakes. E.g. lack of symmetry between Show/Hide and false symmetry between completed/subtasks: Import not mirrored by Export but by Share: Authors of HIG are arguing against including text as a part of an icon. So something like this: would not fly in 1992. I agree, but Tahoe has more serious problems: icons consisting only of text. Like this: It’s unclear where “metaphorical, abstract icon text that is not supposed to be read literally” ends and actual text starts. They use the same font, the same color, so how am I supposed to differentiate? Icons just get in a way: A...Complete? AaFont? What does it mean? I can maybe understand and . Dots are supposed to represent something. I can imagine thinking that led to . But ? No decorations. No effects. Just plain Abc. Really? One might think that using icons to illustrate text transformations is a better idea. Like, you look at this: and just from the icon alone understand what will happen with the text. Icon illustrates the action. Also, BIU are well-established in word processing, so all upside? Not exactly. The problem is the same—text icon looks like text, not icon. Plus, these icons are excessive . What’s the point of taking the first letter and repeating it? The word “Bold” already starts with a letter “B”, it reads just as easily, so why double it? Look at it again: It’s also repeated once more as a shortcut... There is a better way to design this menu: And it was known to Apple for at least 33 years. Operating system, of course, uses some visual elements for its own purposes. Like window controls, resize handles, cursors, shortcuts, etc. It would be a mistake to use those in icons. Unfortunately, Apple fell into this trap, too. They reused arrows. Key shortcuts: HIG has an entire section on ellipsis specifically and how dangerous it is to use it anywhere else in the menu. And this exact problem is in Tahoe, too. Without icons, you can just scan the menu from top to bottom, reading only the first letters. Because they all align: In Tahoe, though, some menu items have icons, some don’t, and they are aligned differently: Some items can have both checkmarks and icons, or have only one of them, or have neither, so we get situations like this: This menu deserves its own category: Same icon for different actions. Missing the obvious metaphor. Somehow making the first one slightly smaller than the second and third. Congratulations! It got it all. I’ve been mentioning HIG a lot, and you might be wondering: is an interface manual from 1992 still relevant today? Haven’t computers changed so much that entirely new principles, designs, and idioms apply? Yes and no. Of course, advice on how to adapt your icons to black-and-white displays is obsolete. But the principles—as long as they are good principles—still apply, because they are based on how humans work, not how computers work. Humans don’t get a new release every year. Our memory doesn’t double. Our eyesight doesn’t become sharper. Attention works the same way it always has. Visual recognition, motor skills—all of this is exactly as it was in 1992. So yeah, until we get a direct chip-to-brain interface, HIG will stay relevant. In my opinion, Apple took on an impossible task: to add an icon to every menu item. There are just not enough good metaphors to do something like that. But even if there were, the premise itself is questionable: if everything has an icon, it doesn’t mean users will find what they are looking for faster. And even if the premise was solid, I still wish I could say: they did the best they could, given the goal. But that’s not true either: they did a poor job consistently applying the metaphors and designing the icons themselves. I hope this article would be helpful in avoiding common mistakes in icon design, which Apple managed to collect all in one OS release. I love computers, I love interfaces, I love visual communication. It makes me sad seeing perfectly good knowledge already accessible 30 years ago being completely ignored or thrown away today. On the upside: it’s not that hard anymore to design better than Apple! Let’s drink to that. Happy New year! During review of this post I was made familiar with Jim Nielsen’s article , which hits a lot of the same points as I do. I take that as a sign there’s some common truth behind our reasoning. Also note: Safari → File menu got worse since 26.0. Used to have only 4 icons, now it’s 18! Thanks Kevin, Ryan, and Nicki for reading drafts of this post.

0 views
tonsky.me 1 months ago

How to get hired in 2025

It’s 2025 and you are applying for a software engineer position. They give you a test assignment. You complete it yourself, send it over, and get rejected. Why? Because it looked like AI. Unfortunately, it’s 2025, AI is spreading like glitter in a kindergarten, and it’s really easy to mistake hard human labor for soulless, uninspired machine slop. Following are the main red flags in test assignments that should be avoided : Avoid these AI giveaways and spread the word! The assignment was read and understood in full. All parts are implemented. Industry-standard tools and frameworks are used. The code is split into small, readable functions. Variables have descriptive names. Complex parts have comments. Errors are handled, error messages are easy to follow. Source files are organized reasonably. The web interface looks nice. There are tests.

5 views
tonsky.me 3 months ago

I am sorry, but everyone is getting syntax highlighting wrong

Translations: Russian Syntax highlighting is a tool. It can help you read code faster. Find things quicker. Orient yourself in a large file. Like any tool, it can be used correctly or incorrectly. Let’s see how to use syntax highlighting to help you work. Most color themes have a unique bright color for literally everything: one for variables, another for language keywords, constants, punctuation, functions, classes, calls, comments, etc. Sometimes it gets so bad one can’t see the base text color: everything is highlighted. What’s the base text color here? The problem with that is, if everything is highlighted, nothing stands out. Your eye adapts and considers it a new norm: everything is bright and shiny, and instead of getting separated, it all blends together. Here’s a quick test. Try to find the function definition here: See what I mean? So yeah, unfortunately, you can’t just highlight everything. You have to make decisions: what is more important, what is less. What should stand out, what shouldn’t. Highlighting everything is like assigning “top priority” to every task in Linear. It only works if most of the tasks have lesser priorities. If everything is highlighted, nothing is highlighted. There are two main use-cases you want your color theme to address: 1 is a direct index lookup: color → type of thing. 2 is a reverse lookup: type of thing → color. Truth is, most people don’t do these lookups at all. They might think they do, but in reality, they don’t. Let me illustrate. Before: Can you see it? I misspelled for and its color switched from red to purple. Here’s another test. Close your eyes (not yet! Finish this sentence first) and try to remember what color your color theme uses for class names? If the answer for both questions is “no”, then your color theme is not functional . It might give you comfort (as in—I feel safe. If it’s highlighted, it’s probably code) but you can’t use it as a tool. It doesn’t help you. What’s the solution? Have an absolute minimum of colors. So little that they all fit in your head at once. For example, my color theme, Alabaster, only uses four: That’s it! And I was able to type it all from memory, too. This minimalism allows me to actually do lookups: if I’m looking for a string, I know it will be green. If I’m looking at something yellow, I know it’s a comment. Limit the number of different colors to what you can remember. If you swap green and purple in my editor, it’ll be a catastrophe. If somebody swapped colors in yours, would you even notice? Something there isn’t a lot of. Remember—we want highlights to stand out. That’s why I don’t highlight variables or function calls—they are everywhere, your code is probably 75% variable names and function calls. I do highlight constants (numbers, strings). These are usually used more sparingly and often are reference points—a lot of logic paths start from constants. Top-level definitions are another good idea. They give you an idea of a structure quickly. Punctuation: it helps to separate names from syntax a little bit, and you care about names first, especially when quickly scanning code. Please, please don’t highlight language keywords. , , , stuff like this. You rarely look for them: “where’s that if” is a valid question, but you will be looking not at the the keyword, but at the condition after it. The condition is the important, distinguishing part. The keyword is not. Highlight names and constants. Grey out punctuation. Don’t highlight language keywords. The tradition of using grey for comments comes from the times when people were paid by line. If you have something like of course you would want to grey it out! This is bullshit text that doesn’t add anything and was written to be ignored. But for good comments, the situation is opposite. Good comments ADD to the code. They explain something that couldn’t be expressed directly. They are important . So here’s another controversial idea: Comments should be highlighted, not hidden away. Use bold colors, draw attention to them. Don’t shy away. If somebody took the time to tell you something, then you want to read it. Another secret nobody is talking about is that there are two types of comments: Most languages don’t distinguish between those, so there’s not much you can do syntax-wise. Sometimes there’s a convention (e.g. vs in SQL), then use it! Here’s a real example from Clojure codebase that makes perfect use of two types of comments: Per statistics, 70% of developers prefer dark themes. Being in the other 30%, that question always puzzled me. Why? And I think I have an answer. Here’s a typical dark theme: and here’s a light one: On the latter one, colors are way less vibrant. Here, I picked them out for you: This is because dark colors are in general less distinguishable and more muddy. Look at Hue scale as we move brightness down: Basically, in the dark part of the spectrum, you just get fewer colors to play with. There’s no “dark yellow” or good-looking “dark teal”. Nothing can be done here. There are no magic colors hiding somewhere that have both good contrast on a white background and look good at the same time. By choosing a light theme, you are dooming yourself to a very limited, bad-looking, barely distinguishable set of dark colors. So it makes sense. Dark themes do look better. Or rather: light ones can’t look good. Science ¯\_(ツ)_/¯ There is one trick you can do, that I don’t see a lot of. Use background colors! Compare: The first one has nice colors, but the contrast is too low: letters become hard to read. The second one has good contrast, but you can barely see colors. The last one has both : high contrast and clean, vibrant colors. Lighter colors are readable even on a white background since they fill a lot more area. Text is the same brightness as in the second example, yet it gives the impression of clearer color. It’s all upside, really. UI designers know about this trick for a while, but I rarely see it applied in code editors: If your editor supports choosing background color, give it a try. It might open light themes for you. Don’t use. This goes into the same category as too many colors. It’s just another way to highlight something, and you don’t need too many, because you can’t highlight everything. In theory, you might try to replace colors with typography. Would that work? I don’t know. I haven’t seen any examples. Some themes pay too much attention to be scientifically uniform. Like, all colors have the same exact lightness, and hues are distributed evenly on a circle. This could be nice (to know if you have OCD), but in practice, it doesn’t work as well as it sounds: The idea of highlighting is to make things stand out. If you make all colors the same lightness and chroma, they will look very similar to each other, and it’ll be hard to tell them apart. Our eyes are way more sensitive to differences in lightness than in color, and we should use it, not try to negate it. Let’s apply these principles step by step and see where it leads us. We start with the theme from the start of this post: First, let’s remove highlighting from language keywords and re-introduce base text color: Next, we remove color from variable usage: and from function/method invocation: The thinking is that your code is mostly references to variables and method invocation. If we highlight those, we’ll have to highlight more than 75% of your code. Notice that we’ve kept variable declarations. These are not as ubiquitous and help you quickly answer a common question: where does thing thing come from? Next, let’s tone down punctuation: I prefer to dim it a little bit because it helps names stand out more. Names alone can give you the general idea of what’s going on, and the exact configuration of brackets is rarely equally important. But you might roll with base color punctuation, too: Okay, getting close. Let’s highlight comments: We don’t use red here because you usually need it for squiggly lines and errors. This is still one color too many, so I unify numbers and strings to both use green: Finally, let’s rotate colors a bit. We want to respect nesting logic, so function declarations should be brighter (yellow) than variable declarations (blue). Compare with what we started: In my opinion, we got a much more workable color theme: it’s easier on the eyes and helps you find stuff faster. I’ve been applying these principles for about 8 years now . I call this theme Alabaster and I’ve built it a couple of times for the editors I used: It’s also been ported to many other editors and terminals; the most complete list is probably here . If your editor is not on the list, try searching for it by name—it might be built-in already! I always wondered where these color themes come from, and now I became an author of one (and I still don’t know). Feel free to use Alabaster as is or build your own theme using the principles outlined in the article—either is fine by me. As for the principles themselves, they worked out fantastically for me. I’ve never wanted to go back, and just one look at any “traditional” color theme gives me a scare now. I suspect that the only reason we don’t see more restrained color themes is that people never really thought about it. Well, this is your wake-up call. I hope this will inspire people to use color more deliberately and to change the default way we build and use color themes. Look at something and tell what it is by its color (you can tell by reading text, yes, but why do you need syntax highlighting then?) Search for something. You want to know what to look for (which color). Green for strings Purple for constants Yellow for comments Light blue for top-level definitions Explanations Disabled code JetBrains IDEs Sublime Text ( twice )

0 views
tonsky.me 4 months ago

Talk: Почему компьютеры не умеют считать? @ Podlodka

Как компьютеры представляют числа – от int и float до NaN, BigInt, decimals и комплексных. Прошлись по всему числовому зоопарку: обсудили, зачем нужны разные типы, где они подводят, и почему 0.1 + 0.2 ≠ 0.3 – не баг, а особенность.

0 views
tonsky.me 5 months ago

We shouldn’t have needed lockfiles

Imagine you’re writing a project and need a library. Let’s call it . You look up its current version, which is , and add it to your dependencies: In turn, the developer of , when writing its version , needed another library: . So they did the same thing: they looked up the version, which was at the time, and added it to the dependencies of : The version of is immortalized forever in the dependencies of . No matter how many other versions of either or are released, will always depend on . Our dependency resolution algorithm thus is like this: The important point of this algorithm is that it’s fully deterministic. Given just the top-level dependencies, it will produce the entire dependency tree, identical every time. It’s also space-efficient: you don’t need to specify all the versions, just the top-level ones. Given , we will always arrive at . So why write it down in a separate file? And that’s it. End of story. Write down your top-level dependencies. The computer will figure out transitive ones. They are guaranteed to be the same, since everything is immutable. The sun is shining, the grass is green, and builds are fully reproducible. But people had to invent lockfiles. Imagine you voluntarily made your build non-reproducible by making them depend on time. If I build my app now, I get and . If I repeat the same build in 10 minutes, I’ll get . Crazy, right? That would be chaos. But this is what version ranges essentially are. Instead of saying “ depends on ”, they are saying “ depends on whatever the latest version is at the time of the build.” Notice that this is determined not at the time of publishing, but at the time of the build! If the author of has published a year ago and I’m pulling it now, I might be using a version that didn’t even exist at the time of publishing! But... why would ’s author write a version range that includes versions that don’t exist yet? How could they know that , whenever it will be released, will continue to work with ? Surely they can’t see the future? Semantic versioning is a hint, but it has never been a guarantee. For that, kids, I have no good answer. The funny thing is, these version ranges end up not being used anyway. You lock your dependencies once in a lockfile and they stay there, unchanged. You don’t even get the good part! I guess, builds that depend on the calendar date are too crazy even for people who believe that referencing non-existing versions is fine. “But Niki, you can regenerate the lockfile and pull in all the new dependencies!” Sure. In exactly the same way you can update your top-level dependencies. “But Niki, lockfiles help resolve version conflicts!” In what way? Version conflicts don’t happen because of what’s written in dependency files. Your library might work with the newer dependency, or it might not. It doesn’t really depend on what the library’s author has guessed. Your library might have a version range of , work with , but not with . Either way, the solution is the same: you have to pick the version that works. And the fact that someone somewhere long time ago wrote doesn’t really help you. “But Niki, if lockfiles exist, there must be a reason! People can’t be doing it for nothing!” You are new in IT, I see. People absolutely can and do things here for no good reason all the time. But if you want an existence proof: Maven. The Java library ecosystem has been going strong for 20 years, and during that time not once have we needed a lockfile. And we are pulling hundreds of libraries just to log two lines of text, so it is actively used at scale. In conclusion, lockfiles are an absolutely unnecessary concept that complicates things without a good reason. Dependency managers can and are working without it just the same. UPD: Reading comments, I see that I missed a part of version resolution that is important. In Maven, if you have conflicting transitive dependencies, the version that will picked is the version closest to the root. E.g.: In this case, will be picked. This is still deterministic, but it lets you override versions when needed. For example, if is released with security patches, you can always add it to the root and that’s the version that will be picked: No need to wait for the whole world to update. Still deterministic. Still no lockfiles. Why not pick the biggest version? Then you’ll lose the ability to override. Get the top-level dependency versions Look up versions of libraries they depend on Look up versions of libraries they depend on

0 views
tonsky.me 6 months ago

Gaslight-driven development

Any person who has used a computer in the past ten years knows that doing meaningless tasks is just part of the experience. Millions of people create accounts, confirm emails, dismiss notifications, solve captchas, reject cookies, and accept terms and conditions—not because they particularly want to or even need to. They do it because that’s what the computer told them to do. Like it or not, we are already serving the machines. Well, now there is a new way to serve our silicon overlords. LLMs started to have opinions on how your API should look, and since 90% of all code will be written by AI comes September , we have no choice but to oblige. You might’ve heard a story of Soundslice adding a feature because ChatGPT kept telling people it exists . We see the same at Instant: for example, we used for both inserting and updating entities, but LLMs kept writing instead. Guess what: we now have , too. Is it good or is it bad? It definitely feels strange. In a sense, it’s helpful: LLMs here have seen millions of other APIs and are suggesting the most obvious thing, something every developer would think of first, too. It’s also a unique testing device: if developers use your API wrong, they blame themselves, read the documentation, and fix their code. In the end, you might never learn that they even had the problem. But with ChatGPT, you yourself can experience “newbie’s POV” at any time. Of course, this approach doesn’t work if you are trying to do something new and unique. LLMs just won’t “get it”. But how many of us are doing something new and unique? Maybe, API is not the place to get clever? Maybe, for most cases, it’s truly best if you did the most obvious thing? So welcome to the new era. AI is not just using tools we gave it. It now has opinions about how these tools should’ve been made. And instead of asking nicely, it gaslights everybody into thinking that’s how it’s always been.

0 views
tonsky.me 6 months ago

Podcast: Datomic: самая рок-н-рольная БД @ Тысяча фичей

Чем Datomic отличается от других баз данных и почему иногда остутствие оптимизатора лучше, чем его присутствие

0 views