> Groups of zeros can be omitted with two colons, but only once in an address (i.e. 2000:1::1, but not 2000::1::1 as that is ambiguous)
Can someone explain why it's ambiguous?
On the subject, IPv6 is one of the strangest inventions on the internet. Its utility and practically are obvious no matter how you look at it except... just one thing.
Network-related things are generally easy to remember and then type from memory: IPv4, domain names, standard port numbers. Back in the day it was the phone numbers, again, easy to remember and dial when you need it. IPv6 is just too long and requires copy/paste all the time. This is the only real reason in my opinion, why IPv6 is doomed to be second-grade citizen for (probably) a few more decades.
> This is the only real reason in my opinion, why IPv6 is doomed to be second-grade citizen for (probably) a few more decades.
Except if you're using a mobile phone, in which case many telcos hand out only IPv6 addresses to handsets. 2018 NANOG presentation "T-Mobile's journey to IPv6":
Your IPv4 packets are getting tunneled to a CGNAT server which has an IP address pool.
Your website will load faster on cellphones if it supports IPv6. This is because the packets take more direct routes (because they don't go to the central CGNAT server) and because less processing is applied to them. Almost all mobile networks are now IPv6-only, with IPv4 traffic tunneled and CGNATted. Apparently T-Mobile is the rare exception.
I've said this since time immemorial, and networking people often dismiss it. "Just use DNS," say people who have never actually worked netops or devops.
The length of the addresses and the clunky nature of their ASCII representation is absolutely the #1 reason the IPv6 has taken this long. User experience is the most powerful force affecting large scale adoption, and IPv6 has poor UX.
I think the UX is partly fixable by creating less horrible ASCII representation, but this would take a lot of coordination that was hard even back then and is virtually impossible now. If someone told me in 500 years we're still running dual-stack IPv4/IPv6 absolutely unchanged, I'd believe it.
Half the reason (literally) the address looks so bad is not because of IPv6 but because everyone keeps choosing to implement randomized in-subnet addresses and cycle through them for privacy reasons.
E.g. 2600:15a3:7020:4c51::52/64 is not too horrible but 2600:15a3:7020:4c51:3268:b4c4:dd7b:789/64 is a monster by unrelated intent of the client.
This is pretty much on the money. IPv6 addressing can be pretty simple if you design your subnets and use low numbers for hosts. But hosts themselves will forgo that and randomly generate 64 bit random host addresses for themselves - some times for every new connection. Now you have thousands of IPv6 addresses for a single computer speaking out to the Internet.
"Modern" tooling in the consumer space is pretty dire for IPv6 support too. The best you can reasonably get is an IPv6 on the WAN side and then just IPv4 for everything local. At least from the popular routers I've experienced lately.
I’ve been amazed for years at the fact that many of the best routers turn V6 off by default.
Of course I know why. If you turn it on it slightly increases edge case issues as complexity always does. Most people don’t actively need it so nobody notices.
Yes, I forgot about SLAAC and worthless privacy extensions.
Privacy extensions are worthless because there are just sooooo many ways to fingerprint and track you. If you are not at least using a VPN and a jailed privacy mode browser at a bare minimum, you are toast. If you’re serious about privacy you have to use stuff like Tor.
V6 privacy extensions are like the GDPR cookie nonsense: ineffective countermeasures with annoying side effects.
SLAAC sucks too. They should have left assignment up to admins or higher level protocols like with V4. It’s better that way.
Most people are just using the ISP provided router as their gateway today anyways. E.g. ATT fiber is proud to advertise to you that it knows about each of your devices on the ONT+Router combo - that's even the only way to set up a port forward (you can't just type in an IP, you have to pick a discovered device).
"But people can NAT the v4 with another router to hide it!" -> sure, and the same crappy solution works with v6.
"But at least prosumers can replace the ONT via cloning the identifiers and certain hardware" -> also no change with v6.
Randomized addresses do have valid use cases though, particularly when connecting to Wi-Fi networks other than your own when set to randomize the MAC per connection (not just the scanning MAC) as well, but I'm just not really convinced this is a realistic example as framed.
IPv4 isn't perfect, but it was designed to solve a specific set of problems.
IPv6 was designed by political process. Go around the room to each engineer and solve for their pet peeve to in turn rally enough support to move the proposal forward. As a bunch of computer people realized how hard politics were they swore never to do it again and made the address size so laughably large that it was "solved" once and for all.
I firmly believe that if they had adopted any other strategy where addresses could be meaningfully understood and worked with by the least skilled network operators, we would have had "IPv6" adoption 10 years ago.
My personal preference would have been to open up class E space (240-255.*) and claw back the 6 /8s Amazon is hoarding, be smarter about allocations going forward, and make fees logarithmic based on the number of addresses you hold.
Only if by "political process" you mean a bunch of people got together (physically and virtually) and debated the options and chose what they thought was best. The criteria for choosing IPng were documented:
> I firmly believe that if they had adopted any other strategy where addresses could be meaningfully understood and worked with by the least skilled network operators, we would have had "IPv6" adoption 10 years ago.
The primary reason for IPng was >32 bits of address space. The only way to make them shorter is to have fewer bits, which completely defeats the purpose of the endeavour.
There was no way to move from 32-bits to >32-bits without every network stack of every device element (host, gateway, firewall, application, etc) getting new code. Anything that changed the type and size of sockaddr->sa_family (plus things like new DNS resource record types: A is 32-bit only; see addrinfo->ai_family) would require new code.
This is a lot of basically sharpshooting, but I will address your last point:
> There was no way to move from 32-bits to >32-bits without every network stack of every device element (host, gateway, firewall, application, etc) getting new code. Anything that changed the type and size of sockaddr->sa_family (plus things like new DNS resource record types: A is 32-bit only; see addrinfo->ai_family) would require new code.
That is simply not true. We had one bit left (the reserved/"evil" bit) in IPv4 headers that could have been used to flag that the first N bytes of the payload were an additional IPv4.1 header indicating additional routing information. Packets would continue to transit existing networks and "4.1" capable boxes at edges could read the additional information to make further routing decisions inside of a network. It would have effectively used IPv4 as the core transport network and each connected network (think ASN) having a handful of routed /32s.
Overlay networks are widely deployed and have very minor technical issues.
But that would have only addressed the numbering exhaustion issues. Engineers often get caught in the "well if I am changing this code anyway" trap.
An explicit goal of IPv6 considered as important as the address expansion was the simplification of the packet header, by having fewer fields and which are correctly aligned, not like in the IPv4 header, in order to enable faster hardware routing.
The scheme described by you fails to achieve this goal.
I am glad you brought this up, that is another big issue with IPv6. A lot of the problems it was trying to solve literally don't exist anymore.
Header processing and alignment were an issue in the 90s when routers repurposed generic components. Now we have modern custom ASICs that can handle IPv4 inside of a GRE tunnel on a VLAN over MPLS at line rate. I have switches in my house that do 780 Gbps.
At the time when it was designed, IPv6 was well designed, much better than IPv4, which was normal after all the experience accumulated while using IPv4 for many years.
The designers of IPv6 have made only one mistake, but it was a huge mistake. The IPv4 address space should have been included in the IPv6 space, allowing transparent intercommunication between any IP addresses, regardless whether they were old IPv4 addresses or new IPv6 addresses.
This is the mistake that has made the transition to IPv6 so slow.
> The IPv4 address space should have been included in the IPv6 space, allowing transparent intercommunication between any IP addresses, regardless whether they were old IPv4 addresses or new IPv6 addresses.
How would you have implemented it that is different from the NAT64 that actually exists, including shoving all IPv4 addresses into 64:ff9b::/96?
> That is simply not true. We had one bit left (the reserved/"evil" bit) in IPv4 headers […]
Great, there's an extra bit in the IPv4 packet header.
I was talking about the data structures in operating systems: are there any extra bits in the sockaddr structure to signal things to applications? If not, an entirely new struct needs to be deployed.
And that doesn't even get into having to deploy new DNS code everywhere.
They didn't use the reserved bit, because there's a field that's already meant for this purpose: the next protocol field. Set that to 0x29 and it indicates that the first bytes of the payload contain a v6 address. Every v4 address has a /48 of v6 space tunnelled to it using this mechanism, and any two v4 addresses can talk v6 between them (including to the entire networks behind those addresses) via it.
If doing basically exactly what you suggested isn't enough to stop you from complaining about v6's designers, how could they possibly have done any better?
This would require new software and new ASICs on all hosts and routers and wouldn't be compatible with the old system. If you're going to cause all those things, might as well add 96 new bits instead of just 2 new bits, so you won't have the same problem again soon.
IPv6 is literally just IPv4 + longer addresses + really minor tweaks (like no checksum) + things you don't have to use (like SLAAC). Is that not what you wanted? What did you want?
And what's wrong with a newer version of a thing solving all the problems people had with it...?
There are more people than IPv4 addresses, so the pigeonhole principle says you can't give every person an IPv4 address, never mind when you add servers as well. Expanding the address space by 6% does absolute nothing to solve anything and I'm confused about why you think it would.
I finally clicked when I worked out it was 2^64 subnets . You have a common prefix of you /48, which isn’t much longer than an ipv4 address - especially as it seems everything is 2001::/16, which means you basically have to remember a 32 bit network prefix just like 12.45.67.8/32.
That becomes 2001:0c2d:4308::/48 instead
After that you just need to remember the subnet number and the host number. If you remember 12.45.67.8 maps to 192.168.13.7 you might have
2001:0c2d:4308:13::7
So subnet “13” and host “7”
It’s not much different to remebering 12.45.67.8>192.168.13.7
Exactly enough to fill out the address, which is always the same length. BTW, IPv4 does basically the same thing. The address 127.1 is equivalent to 127.0.0.1.
Not really the same, the mechanics are different and this particular behaviour is pretty much an accident, not abbreviation.
In IPv4 you also have 127.257 equal to 127.0.1.1, 123456789 equal to 7.91.205.21, and 010.010.010.010 is a well-know DNS server. This notation is also rejected by most implementations.
It is? Those alternate IPv4 notations are all accepted by Linux, FreeBSD, and MacOS. I remember playing around with "alternate notations" 30+ years ago on old SunOS boxes.
I am not clear what your point is. The parent's point stands. A double colon only represents zeros (that were compressed and are not displayed).
Your link does not show different addresses from a valid compression, it shows different addresses from an invalid compression. The link examples what we don't do.
Conversely, if we compress the expanded addresses in your link, we will get 2 different compressed addresses.
> IPv6 is just too long and requires copy/paste all the time.
That is only true for autogenerated/SLAAC IPs. In contrast, manually assigned IPs are often much simpler and easier to remember in IPv6 than in IPv4. I have one common subnet prefix that can be uniformly split to end networks and last number in IP address for such network always end with 0 (and therefore the first device is xxx::1). While in IPv4 i had multiple prefixes, each split non-uniformly based on how many devices was expected to be on that end network, and because most end network prefixes were smaller than /24 (say /26-28), the last number of IP address varies between these networks.
I mean yes, but there’s no escape from the fact that ip addresses need to be longer as amount of devices on the internet already exhausted the pool of IPv4 addresses by multiple orders of magnitude.
I guess it could be possible to implement sort of mnemonic phrases for addresses, à la bip-39, but it would be just trading one kind of pain for another.
It’s a really complicated rule called “subtraction”. Addresses are always 128 bits long, or 8 groups of four hex digits. 2000::1 is two groups, so you need six groups in between to make 2000:0000:0000:0000:0000:0000:0000:1. But I don’t know why people always ask this, because it’s always the computer you are typing addresses in to that does the subtraction. You never ever have to type out the whole address. Just type the shortened version, because 2000::1 _is_ the whole address.
the :1 is short for :0001 basically and then just put that bit of the address at the very end and put the first bit of the address at the front, and then just fill each missing group inbetween with 0000
Well, okay, show us how to follow those instructions then.
"the :1 is short for :0001 basically" is easy enough: you get 2001::0001::0001.
Then "just put that bit at the very end" -- but which bit? If it means the ":0001", then there's two of them and they can't both go at the very end. If not, then it fails to specify which bit. Either way I don't see how these instructions are followable at all, let alone easily.
My answer was too terse. IF there was two :: in the address, then the length of EACH :: denoted section is not known. It can be either longest left :: or longest right :: and that wasn't defined, because the rule is THERE IS ONLY ONE :: section.
I've been using Linux for almost 20 years, including sed a lot of that time, I'm sure I've heard it before, I must have, but when parent wrote it I was like "aah, that makes sense".
I never forget what it does obviously, I use it at least weekly and most of the time daily. But if you asked me what "sed" stand for I'd probably not recall. I might have attempted to work in "extended" somewhere in a guess, because of ex the editor, but besides that :/
Don't forget that you need to know English for that to work. I'm pretty sure most Unix users don't speak English (most computer users definitely don't). I interact with people who know few words besides "hello" and "goodbye", and for them "sed" is a nonsense term, just a set of letters randomly thrown together. Same as e.g. Excel, a random token that means nothing.
sed is just an example, of course, the author's point doesn't hold much weight for many (most?) users globally.
lol no. There are literally a hundred plus Unix tools and commands. I couldn’t tell you what 90% of them mean. I sure as hell couldn’t have told you what sed stood for. And if you asked me tomorrow I also wouldn’t be able to tell you.
C programmers are great. I love C. I wish everything had a beautiful pure C API. But C programmers are strictly banned from naming things. Their naming privileges have been revoked, permanently.
It's `xaf`, because the modern world is way too complex for simple Germanic rules to solve it.
But GNU tar was never the issue. It's almost completely straight forward, the only problem it has is people confusing the tar file with the target directory. If you use some UNIX tar, you will understand why everybody hates it.
Someone once tried this on me during Friday drinks and I successfully conquered the challenge with "tar --help". The challenger tried in vain to claim that this was not valid, but everyone present agreed that an exit code of zero meant that it was a valid solution.
Some drunks in a gnu-shaped echo chamber concluded that the world is gnu-shaped. That's not much a joke, if there is one here. Such presently popular axioms as "unix means linux" or "the userland must be gnu" or "bash is installed" can be shown as poor foundations to reason from by using a unix system that violates all those assumptions. That the XCDD comic did not define what a unix system is is another concern; there are various definitions, some of which would exclude both linux and OpenBSD.
I seem to remember "tar xvf filename.tar" from the 1990s, I'll try that out. If I'm wrong, I'll be dead before I even notice anything. That's better than dying of cancer or Alzheimer's.
z requires it's compressed with gzip and is likely a GNU extension too (it was j for bzip2 iirc). It's also important to keep f the last because it is parametrized and a filename should follow.
So I'd always go with c (create) instead of x (extract), as the latter assumes an existing tar file (zx or xz even a gzipped tar file too; not sure if it's smart enough to autodetect compress-ed .Z files vs .gz either): with create, higher chances of survival in that xkcd.
is always a valid command, whether file.name exists or not. When the file doesn't exist, tar will exit with status '2', apparently, but that has no bearing on the validity of the command.
Compare these two logs:
$ tar xvzf read.me
tar (child): read.me: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
$ tar extract read.me
tar: invalid option -- 'e'
Try 'tar --help' or 'tar --usage' for more information.
Do you really not understand the difference between "you told me to do something, but I can't" and "you just spouted some meaningless gibberish"?
The GGP set the benchmark at "returns exit code 0" (for "--help"), and even with XKCD, the term in use is "valid command" which can be interpreted either way.
The rest of your slight is unneccessary, but that's your choice to be nasty.
Like I said, I was operating on a lot of zipped tars. Not sure what you are replying about.
The other commenter already mentioned that the xkcd just said "valid", not return 0 (which to be fair is what the original non xkcd required so I guess fair on the mixup)
Oh, just funny mental gymnastics if we are aiming for survival in 10 seconds with a valid, exit code 0 tar command. :)
As tar is a POSIX (ISO standard for "portable operating system interfaces") utility, I am also highlighting what might get us killed as all of us are mostly used to GNU systems with all the GNU extensions (think also bash commands in scripts vs pure sh too).
Hehe fair enough in that case. Tho nothing said it had to work on a tar from like 1979 ;)
To me at least POSIX is dead. It's what Windows (before WSL) supported with its POSIX subsystem so it could say it was compatible but of course it was entirely unusable.
Initial release July 27, 1993; 32 years ago
Like, POSIX: Take the cross section of all the most obscure UNICES out there and declare that you're a UNIX as long as you support that ;)
And yeah I use a Mac at work so a bunch of things I was used to "all my life" so to speak don't work. And they didn't work on AIX either. But that's why you install a sane toolchain (GNU ;) ).
Like sure I was actually building a memory compactification algorithm for MINIX with the vi that comes with MINIX. Which is like some super old version of it that can't do like anything you'd be used to from a VIM. It works. But it's not nice. That's like literally the one time I was using hjkl instead of arrow keys.
That's part of the point, I believe. It's not about being always able to guess the function from first sight. It's also about the function and name serving as mnemonic to each other once you understand how it got named.
I think perhaps the articles argument gets less strong then?
It's claimed grep is "well named" because even though it's not obvious when you first read it, that it being a contraction for "global reg ex print" and hence memorable. I'm not sure the same argument can't be made for libsodium which assuming the reader is familiar with NaCl (the same as the assumption that the previous reader is familiar with regex) then it's an equally memorable name for your crypto library.
There's always a consideration about the context the name is intended and likely to be used in. The article mentions engineering naming and "ibeam", but engineering has it's own technical names an jargon as well. Most people wont know what "4130 tube" means, but people who build bicycle frames or roll cages will - and they're likely to use the less specific term "chromoly" if the don't need to distinguish between 4130 and 4145.
In my head "libsodium" is similar - if you don't know what it (and NaCl) mean, you 100% should keep out of that part of the codebase.
Names fall on a spectrum on this argument. Sodium is not really random because of the use of "salt" on crypto. It's like saying that libsodium is part of your crypto. awk is more random.
The argument goes stronger with projects where the creator seemed to just roll the dice with the name.
One additional complication with grep (and other CLI tools) is that the name itself is part of the day to day UX. It needs to be short, easy to say, and easy to type. With a library the API that is contained within serves the analogous role.
"libsodium" -> "salt" -> "salting is something tangentially related to cryptography" is significantly better as a mnemonic than "awk stands for the author's initials".
Same for grep - with, I guess, the proviso/assumption that you know what regular expression means, which might have been a fair assumption for the sort of people who had command line access to Unix systems in the 70s/80s, but may no longer be valid for developers under 30 who grew up with Windows and were perhaps trained in 6 or 26 week "bootcamps" that didn't have time to cover historical basics like that?
Regular expressions are more of a CS topic (regular languages), though common abbrevs of "re" and "regex" I've only seen in the wild pre and post my formal education in CS.
Yeah, I'd totally expect CS grads, old school Unix sysadmins, and Perl hackers to be fully familiar with Regex. Not so sure I'd expect that from bootcamp front end webdev "grads", self touch game devs, or maybe (I'm not sure?) engineers who have spent their careers in Microsoft dev environments.
The early internet was like some settlers' shacks, built uncontrollably and unsystematically whereas the modern web is all skyscrapers, residential and business. Uniform apartments, uniform offices all looking very similar differeing in only subtle interior design details here and there.
Should we go back to the shack era? Of course not. But maybe we should start a new era of land exploration and start over. It shouldn't necessarily be Internet 3.0, might be something else completely. AR/VR? Possibly although that has already failed once.
The only thing missing from your analogy is the fact that the shacks were filled with personal diaries and curios, while the skyscrapers are mostly chock-full of homogenous sewage slurry.
Also the shacks weren’t really particularly shabby or anything, they were just more like well-enough-constructed single family homes.
Old websites before scripting became popular were pretty much solid in that boring-tech way. Hardware and networks were not as reliable, but the sites themselves could be fine via simplicity.
Modern overdesigned sites are sort of like modern apartment buildings: shitty build quality under fake plastic marble and wood.
Keep in mind the early websites were mostly built by an enthusiast minority, technical or not but willing to learn HTML and Netscape Composer. You can't expect the whole humanity to be as enthusiastic. The skyscraper era, no matter how much we all hate it, makes the web more democratic: it gives everyone some standardized space (Facebook, Youtube, etc) with algorithmized discovery which is parking and elevators if you want to continue the analogy.
Hard to live through what social media has done to society over the past decade without at least entertaining the idea that the higher barrier to entry of being online was maybe not a bad thing.
I wouldn't agree that the higher barrier to entry was a good thing, but I also would say that the barrier to entry was actually pretty low, with angelfire, geocities, etc. Dreamweaver + other wysiwyg, and the lack of a necessity of a giant js framework with bundling and tree-shaking.
The problem is that the barrier to entry got too low, so it was necessary for large companies to interpose themselves between producers and audiences, starting with google (becoming something other than a grep for the web, and instead becoming the editor and main income source for the web) and expanding outwards into facebook.
Remember that we started with walled gardens like AOL and Compuserve, and the web (and the end of those companies) was people desperate to break out of them. Now people have been herded in again since the indexers bought the ad companies.
I don't disagree but notice how it's about the second decade of Web 2.0, not the first one. Profit-driven algorithms is a separate era in its own right. I.e. you can't blame the skyscrapers themselves for your shitty life, you just need to demand more regulation.
yes, for sure! It was a different time. Early website authors were pioneers. They had something worth sharing and they thought it worthwhile enough to learn some coding. Nobody was trying to push ads and monetize, and there was no ubiquitous tracking or cookies
If we're talking about the internet before Eternal September, maybe, but putting up a site on Geocities or Tripod or using Dreamweaver certainly was not a high barrier to entry.
Facebook and YouTube are top-down managed systems, and I think it is a real disservice to the idea of democracy to call this sort of thing “more democratic.” They are democratic like a mall is, which is to say, not.
I like to compare today's web to radio in the late 1800s and early 1900s.
Back then, if you could piece together a transmitter and throw an antenna up, you were a broadcaster and many broadcast whatever they felt like. Just like today's internet.
Social media is the CB radio of the 1970s and 80s when anyone could buy a small rig and do all kinds of weird and wild things for cheap.
But, eventually, something had to reign in all that and the FCC along with international laws and standards came up to calm all that down. In the same way, I think the internet will eventually become licensed and regulated.
The rationale behind the FCC is that it's regulating a limited resource (spectrum space.) The web is not a limited resource (although bandwidth is, but that's a different debate.) The web is also international, and we're already seeing conflicts where one country tries to force their regulations onto another. That metaphor just doesn't work where the web is concerned.
I agree that the web in the US, and specifically large social media platforms, will probably be regulated because that seems to be one of the few things both parties agree on for their own reasons. But more so because the government wants to control information and surveil citizens. I think the balkanization of the web as a whole into smaller, closed networks is probably inevitable.
But what's most depressing of all is how many people in tech and on HN would be thrilled if one needed a license to publish on the internet just because that would implicitly push most people off of the web and leave it for a privileged elite.
As bad as social media can be (and I think its harm is often oversold for political ends) having a space where anyone can publish and communicate and create freely, where different platforms can exist and cater to different needs, where media isn't entirely controlled and gatekept by corporations, is critically important. More important than any other communications paradigm before it, including the printing press.
It's really going to be sad when we burn it all down, because it seems unlikely anyone is going to make something as free and open as the web ever again.
> But, eventually, something had to reign in all that and the FCC along with international laws and standards came up to calm all that down.
No, it actually stayed pretty lively until the 90s, when the government decided that there could be huge monopolies in media, all the stations were bought up by like 6 guys, and were automated to play Disney music 24 hours a day.
> Should we go back to the shack era? Of course not.
I am not sure. Different people want different things. I ran a Hetzner cloud instance where I toss a simple webpage with locally hosted travel photos for friends and family. And a Jupiter server (with a very weak password) on the same instance for myself and any friend when we want something more powerful than a calculator.
And this messy, improperly organized, breaking all design patterns way works just fine for me. So I'm fine with a shack for personal communication and as a personal space. My 2c.
AI in its present form is probably the strangest and the most paradoxical tech ever invented.
These things are clearly useful once you know where they excel and where they will likely complicate things for you. And even then, there's a lot of trial and error involved and that's due to the non-deterministic nature of these systems.
On the one hand it's impressive that I can spawn a task in Claude's app "what are my options for a flight from X to Y [+ a bunch of additional requirements]" while doing groceries, then receive a pretty good answer.
Isn't it magic? (if you forget about the necessity of adding "keep it short" all the time). Pretty much a personal assistant without the ability of performing actions on my behalf, like booking tickets - a bit too early for that.
Then there's coding. My Copilot has helped me dive into a gigantic pre-existing project in an unfamiliar programming language pretty fast and yet I have to correct and babysit it all the time by intuition. Did it save me time? Probably, but I'm not 100% sure!
The paradoxicality is in that there's probably no going back from AI where it already kind of works for us individually or at org levels, but most of us don't seem to be fully satisfied with it.
The article here pretty much confirms the paradox of AI: yes, orgs implement it, can't go back from it and yet can't reduce the headcount either.
My prediction at the moment is that AI is indeed a bubble but we will probably go through a series of micro-bursts instead of one gigantic burst. AI is here to stay almost like a drug that we will be willing to pay for without seeing clear quantifiable benefits.
It’s a result of the lack of rigor in how it’s being used. Machine learning has been useful for years despite less than 100% accuracy, and the way you trust it is through measurement. Most people using or developing with AI today have punted on that because it’s hard or time consuming. Even people who hold titles of machine learning engineer seem to have forgotten.
We will eventually reach a point where people are teaching each other how to perform evaluation. And then we’ll probably realize that it was being avoided because it’s expense to even get to the point where you can take a measurement and perhaps you didn’t want to know the answer.
Like a proverbial broken clock which shows correct time twice per 24 hours, AI may "show correct time" for 99% of prompts, but doesn't deserve any more trust.
A hammer doesn't always work as desired, it depends on your skills plus some random failures. When it works however, you can see the result and are satisfied with it - congratulations, you saved some time by not using a rock for the same task.
> Is the software easy to take in at a glance and to onboard new engineers to?
This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement?
"Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.
So when someone says "code should be readable", to whom exactly?
Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns.
Yes, it's all subjective, and depends on the reader's expertise and existing familiarity with the codebase. But arguing that code readability isn't at thing, because it's subjective, is an absurd take. Would you claim that Joyce's Ulysses is equally readable as Seuss's The Cat in the Hat?
I see this argument pattern a lot, so looked into what the name is.
Apparently it's called Sorites paradox: https://en.wikipedia.org/wiki/Sorites_paradox or the "continuum fallacy" in which something that's continuous is dismissed as not existing because we can't divide it into clear categories.
Readability without a clarification is a non-concept. You can't say "X should be readable" without giving some context and without clarifying who you are targeting. "Code should be readable" is a non-statement, yes.
Add "to most developers" for context and you'll probably get exactly what original claim meant.
It's not a non-statement. Rich Hickey explains it well, readability is not about the subjective factors, it's mostly about the objective ones (how many things are intertwined? the code that you can read & consider in isolation is readable. The code that behaves differently depending on global state, makes implicit assumptions about other parts of the system, etc - is unreadable/less readable - with readability decreasing with number of dependencies).
"to most developers who are most likely to interact with this code over its useful lifetime."
This means accounting for the audience. Something unfamiliar to the average random coder might be very familiar to anyone likely to touch a particular piece of code in a particular organization.
>"Code should be readable" is a non-statement, yes.
Oh, I completely disagree here. Take obfuscation for example, which you can carry on into things like minimized files in javascript. If you ever try to debug that crap without an original file (which happens far more than one would expect) you learn quickly about readability.
>> Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns.
Usually that means something less than "perfect" from the perspective of the writer. Applying to much DRY, SOLID, DI and other "best practices" will make it very hard to understand. Pretend you have about 20 less IQ points than you actually have when writing the code - you will thank yourself when you come back to it.
> Reading -- and understanding -- code requires twice the brainpower of writing code. So if you used every bit of your intelligence to write 'clever' code, you won't be able to maintain it because it requires twice your intelligence to read it again.
Einstein's words are oh so suitable as well:
> Everything should be made as simple as possible, but not simpler.
The trap people fall into is calling The Cat in the Hat unreadable compared to Joyce's Ulysses because The Cat in the Hat they're reading is written in German and all they understand is English.
I didn't say readability is subjective. I'm just asking, when someone says "code should be readable" without any clarifications, what does it really mean?
Big companies may actually have an answer to that: "since we require at least 2 years of experience in the area from new hires, all code should be readable at that level".
However startups may prioritize something else over readability at that level, for example: move fast, produce the most minimalist code that would be easy to maintain for people like you.
My point being, "code should be readable" should always come at least with a footnote that defines the context.
Developers coming from functional programming and developers coming from C programming, for instance, have very different definitions of "readable", and neither is obviously wrong.
Similarly, developers used to channel-based, async-based or mutex-based concurrent programming will all have very different criteria for "readable" code, again none of them obviously wrong.
Those are just paradigms, ways of solving problems. There’s a difference between familiarity and readability. Sometimes you have to learn stuff before understanding them. Readability is how easy it is to do that, given familiarity with the base concepts that the code use.
Yet it's pretty easy to find people who consider that `map()` or `filter()` are simply not readable – or, on the other side of the aisle, that having a loop variable is detrimental to readability.
And of course, these criteria change with time, industry and programming language used.
I have a formal proof for you that it is a non-concept. If code can be read and interpreted by a computer, it means it can in principle be read by a human. There are of course some edge cases like obfuscated JavaScript or binary executable that some people are able to read and understand.
The question comes down to being reasonably readable and we are back to square one: "reasonable" is very relative. In my early days I could read 8086 binary code (in hex) and understand what it does, it was literally at the very edge of readability but it wasn't unreadable.
You are using a different definition of readable than most people are. Most people are using it to mean "the target audience can read and understand the code, and do so in a way/context that allows them work with it". Your definition seems to be "can read the symbols on the screen".
I can read Assembly. I can, in some cases, figure out what that Assembly is doing. I can not, however, work productively with it. I can read Assembly but would not consider it readable.
Speaking of those equations, as he wrote them they were considered rather impenatrable and the modern ones are considered much more beautiful and 'readable' but that was the work of Heaviside and others.
> Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.
When we talk about a language's readability we're typically talking about 'accidental complexity', to use Brooks' term, [0] and not the 'essential complexity' of the problem being solved. For a hairy enough algorithm, even pseudocode can be difficult to understand.
Readability applies in mathematics too, as a bad notation may make formulae unnecessarily difficult to comprehend.
> So when someone says "code should be readable", to whom exactly?
I'll have a go: to another competent engineer familiar with the general problem domain but not familiar with your specific work. This includes yourself in 2 years time.
This seems rather like the question of readability for scientific writing. Research papers should be readable to other researchers in the field, but they aren't generally expected to be readable to a general audience.
It is hardly worth bothering how readable is "local code".
Following the same patterns across large parts of the codebase is what makes the codebase as a whole readable. Those patterns may even be complex, as long as they are used over and over without too much deviation and flag-explosion the codebase will be readable.
In short local isolated code can be as bad to read as it wants, as long as it doesn't infect the codebase as a whole (like through the use of shared mutable state or through a bad API).
Code readability isn't a metric. It is a tradeoff. It basically boils down to: if in doubt will that programmer go with the more readable version of the code or do they stick with the slightly terse, clever hack?
Call me naive, but I would presume that even a junior, once they start working at a company, should be familiar enough with a language that they know all the basic syntax, idioms etc. Still, even if they are, over-using some language features will make your code less readable (to anyone). E.g. some will prefer good ol' if/else to the notorious ternary operator and its many descendants. But that brings us back to your own personal taste...
I disagree. The ability of someone to read code doesn't grow exponentially, after a few years of experience everyone hits the same plateau. More years of experience does not mean you can understand more complex code.
That is to say, if you target "readable to the majority of engineers with 3-4 years of experience, without them getting confused" then you've hit the mark.
> Apple has a max-efficiency design that's excellent for personal computing. Intel/AMD have aging max-performance designs that do beat Apple at absolute peak...
Can you explain then, how come switching from Intel MBP to Apple Silicon MBP feels like literally everything is 3x faster, the laptop barely heats up at peak load, and you never hear the fans? Going back to my Intel MBP is like going back to stone age computing.
In other words if Intel is so good, why is it... so bad? I genuinely don't understand. Keep in mind though, I'm not comparing an Intel gaming computer to a laptop, let's compare oranges to oranges.
If you take a peak-performance-optimized design (the Intel CPU) and throttle it down to low power levels, it will be slower than a design optimized for low power (the Apple CPU).
"let's compare oranges to oranges"
That's impossible because Apple has bought up most of TSMC's 3nm production capacity. You could try to approximate by comparing Apple M4 Max against NVIDIA B300 but that'll be a very one-sided win for NVIDIA.
> That's impossible because Apple has bought up most of TSMC's 3nm production capacity. You could try to approximate by comparing Apple M4 Max against NVIDIA B300 but that'll be a very one-sided win for NVIDIA.
Have you not heard that Intel's Lunar Lake is made on the same TSMC 3nm process as Apple's M3? It's not at all "impossible" to make a fair and relevant comparison here.
> Can you explain then, how come switching from Intel MBP to Apple Silicon MBP feels like literally everything is 3x faster, the laptop barely heats up at peak load, and you never hear the fans? Going back to my Intel MBP is like going back to stone age computing.
My understanding of it is that Apple Silicon's very very long instruction pipeline plays well with how the software stack in MacOS is written and compiled first and foremost.
Similarly that the same applications take less RAM in MacOS than even in Linux often even because at the OS level stuff like garbage collection are better integrated.
I did not say "Intel is so good". I said "x86 peak single-thread performance is just a hair better than Apple M-series peak".
Pretty much everything else about the M-series parts is better. In particular, Apple's uncore is amazing (partly because it's a lot newer design) and you really notice that in terms of power management.
And then there are third-tier historical medieval towns that are 100% walkable and you again don't need a car.
My ideal city of the future is a small walkable town with everything within a 15-20 minute walk, possibly a part of a conglomerate of towns that run trains or buses between them.
I currently live in one such historical town in Southern Europe that's protected by Unesco. The streets are so narrow that not only there's no public transport, all non-resident and non-delivery traffic is prohibited and there's no Uber even. And yet you have everything you need for life and work within a 15-20 minute walk max. More for remote work, obviously.
An ideal city of the future doesn't need to be medieval but maybe we should go back to a city planning concept that is made for humans and not cars. And you know, narrow pedestrian streets are totally fine, they are cute!
> And then there are third-tier historical medieval towns that are 100% walkable and you again don't need a car.
Ah yeah sure I'll just find work in a place and then buy a house there. It's not like 3+ decades of mismanagement on migration and internal policies left even places 30+ minutes by car from work unafforable by mere mortals.
> third-tier historical medieval towns that are 100% walkable
Very many people, including me, want to live in a glorious walkable bijou old-town stone apartment, except they can't afford to because they stopped building them like that in about 1756 and the only jobs within walking distance of the old town are in hospitality and those do not pay the salaries to buy one of the treasured old town apartments from under an AirBnB host.
And if it's a really small, non-tourist town in the middle of nowhere, it may not even have the hospitality sector. So, yes, that bijou property may indeed only cost 50,000 euros, and yes, you can walk to the boulangerie or the confitería or whatever but you're probably going to need a car to get out of your tiny town and go to work or basically anywhere else.
Or you could work remotely or hybrid, or take a 30-60 minute wifi-enabled commuter train to the big city for your big city job, clocking in and handling your emails during your commute and doing the last bits of work on your way home.
It's interesting to me seeing the different ways that different people respond to our modern urban hellholes. I don't want to live in a city at all, I want to live in at most a village where people all have their own land, and the village 'center' is just the most convenient nexus of property lines, where people could set up the local market.
I always sort of assume people who are into de-urbanization are also de-dev, because I don't see how or why the large-scale industrial base would be needed or could be sustained with only smaller, distributed cities, but it's interesting to hear another perspective.
You only have everything you need for work in such a city if your "work" is limited to small offices, restaurants, and retail shops. So you're excluding everything related to manufacturing, agriculture, resource extraction, logistics, military, etc. You know, all of that stuff that keeps modern industrial civilization operating and allows quaint medieval towns to continue existing at all. If you like where you live that's great, but it's hardly ideal and certainly not scalable.
> all of that stuff that keeps modern industrial civilization operating and allows quaint medieval towns to continue existing at all
That doesn't make sense to me. Medieval towns existed for centuries before industrial civilization and without it we might see a drastic increase in medieval style living...
In any case the poster is talking about their own ideal future scenario, maybe leaving out the details like the robots working in underground manufacturing facilities or fusion-powered hydroponic vertical farms etc.
Why? It's a good grammatical equivalent to the full stop for the programmer. It can serve as useful context for the compiler. And it's only one character. Antagonism over semicolons is another strange symptom of conciseness at all costs. If you want APL, just use APL.
That’s why when we write, we use commas and periods. It tells the reader when a thought ends and the next begins. A semi-colon is the traditional period in programming. Not everything fits on one line. Python managed to pull it off and now everyone thinks it’s the right way… it’s just “a way” but by no means modern or right. JavaScript made them optional, but it results in ambiguous parsing sometimes, so it’s not a good idea there either.
In any case, I doubt a run on sentence is “meaningless” but it is hard to parse.
In other words, just like with autonomous driving, you need real world experience aka general intelligence to be truly useful. Having a model of the world and knowing your place in it is one of the critical parts of intelligence that both autonomous vehicle systems and LLM's are missing.
Can someone explain why it's ambiguous?
On the subject, IPv6 is one of the strangest inventions on the internet. Its utility and practically are obvious no matter how you look at it except... just one thing.
Network-related things are generally easy to remember and then type from memory: IPv4, domain names, standard port numbers. Back in the day it was the phone numbers, again, easy to remember and dial when you need it. IPv6 is just too long and requires copy/paste all the time. This is the only real reason in my opinion, why IPv6 is doomed to be second-grade citizen for (probably) a few more decades.
reply