Some good rants in there. Particularly enjoyed the Candela and Hertz ones. Plenty of small stuff I wouldn’t have thought about as well, e.g. flour measurements:
// The density of flour depends on the
// measuring method. "Scooped", or
// "dip and sweep" refers to dipping a
// measure into a bin, and then sweeping
// the excess off the top. "Spooned"
// means to lightly spoon into a measure
// and then sweep the top. Sifted means
// sifting the flour directly into a
// measure and then sweeping the top.
I loved Alan’s Spinal Tap reference while ranting discussing the “international prototype”:
// I dislike having a prefixed unit as the base reference.
// What a horrible decision. Why don't you just have it go to
// ten and make ten a little louder?
Yeah, some people preach the perfect rationality of SI so hard that you’d think they must believe that a cube one meter on a side has a volume of one liter, and if you fill it with water (at STP) that water will have a mass of one gram.
The current system of Meter - Kilogram - Second is just an historical accident. The British used to use cgs (centimeter - gram - second) while the French used MTS (metre - tonne - second).
It isn’t just a historical accident: the original metric prototypes were the mètre des archives and the kilogramme des archives made in 1799, and there’s a direct line from them via the 1880s replacement prototypes to the current SI. There were deviations like cgs and MTS, but all calibration of tools and instruments had a metrological trace back to the kilogramme.
So most of the blame goes to the savants of the académie des sciences who made a deliberate choice that their unprefixed units would be the metre (1/10000 quadrant of latitude), litre (1/1000 m^3), and gramme (mass of 1/1000 litre of water).
Yeah it’s weird. The metre and the yard are of similar dimensions, and I don’t know how the litre and contemporaneous volume definitions differ. Why is the gram so much smaller?
Part of the rationale for the metric system at the time was to harmonize/eliminate regional differences of weights and measures in France. Maybe using the smaller unit made it easier to define existing weights in terms of numbers closer to integer values instead of fractional (compare the modern pound which is 0.4536 kg or 453.6 g).
BTW the kg is not the only “irrational” unit, almost no-one uses the are as a measure of area, it’s all hectares…
I don’t know if it’s just me, but I find Typescript written with Effect somewhat hard to grok.
It sounds like an interesting project but when I look at the Without Effect and With Effect code samples on https://effect.website, my immediate reaction is that I’ll take the Without Effect version.
From this post, it seems somewhat nice that the final “effect” of a chain of actions is hoisted up to the top and you can see what it returns if it succeeds or fails.
const success: Effect.Effect<number, never, never> = Effect.succeed(42)
const fail: Effect.Effect<never, Error, never> = Effect.fail(
new Error("Something went wrong")
)
But those chains of pipes… That doesn’t seem to be the most readable to me.
My ears definitely perk up at the mention of structured concurrency (I wrote a blog post about it in Rust).
From looking through the website a bit, I was missing some of the “why” for this approach though. This blog post explains it more, but I’m still not sure how big of an issue this is in TS/JS land: https://frontside.com/blog/2023-12-11-await-event-horizon/
For me, the problem reduces down to async flow control and structured concurrency is a fantastic way to manage it. This is why structured concurrency is such a great tool for TS since the node/browser is single-threaded and requires strong concurrent tooling. It’s a great fit.
I agree. The pitch of “the missing standard library for TypeScript” is extremely off-putting. I can imagine balls of spaghetti code because Effect is neither a standard nor a language. That positioning is going to mean that everybody invents best practices and it’ll be used either too much or too little.
I’d love to see an effect system in TS but it needs to be language level for it to be practical.
For the last few months, I’ve been obsessed with Decker and Lil. It’s just such a beautiful little ecosystem for hacking together reasonably decent apps and scripts in no time at all.
The last 2 days, I’ve been moving a bunch of spreadsheets that I used for figuring out marathon training schedules.
But, I’ve also got various Lil scripts that generate weather report web pages via cron every few hours, an RSS reader, a bug tracker, a static site generator, a half-assed web browser…a bunch of stuff that I wouldn’t dare show the public, but that are fun to hack around on. Some day I’ll get around to making my Eton Wall Game video game that I have been promising myself I will make for years. I envision it as interactive fiction, but maybe it’ll be a bad pong adaptation. Who knows?
One fun consequence of being able to run every hash in parallel is that you could route traffic to each commit based on a multi-arm bandit optimization. That would mean highly efficient canary deploys for free.
Depending on your traffic volume it could also make most A/B tests (where the hypothesis is “does not decrease metric”) moot. Fewer conditionals in your code base by virtue of your entire code base being under experiment.
Depending on your traffic volume it could also make most A/B tests (where the hypothesis is “does not decrease metric”) moot. Fewer conditionals in your code base by virtue of your entire code base being under experiment.
Yes - in fact, because the instrumentation is so much more thorough, every change can be seen as an A/B test, with its own bucket of metrics!
As you gain confidence in each commit you can ramp traffic to it. The “canary” size would be related to the regret of your algorithm.
The canary would be efficient because routing decisions could happen immediately rather than in some time-period like most canary setups today. If a commit ever serves a single 500 there’s no reason to serve it anymore! The dev workflow would be amazing because there would be virtually 0 cost to just trying things and testing against prod.
For the last 5 years or so I’ve been working on safety-critical and safety-critical-adjacent software and hardware (UAV payloads). As a result, I’ve had an interesting mental shift that definitely has me seeing safety assessments and thinking in other contexts.
This is all kind of an off-the-cuff brain dump here. We usually think of safety-critical systems as “systems that will kill or severely injure people if they fail” and those kinds of systems definitely do deserve a severe degree of analysis and scrutiny, but overall it really is a spectrum. A couple of examples off the top of my head (many coming from looking at the home screen on my phone):
Backups: how robust is your company’s database backup infrastructure? Would the business survive If someone accidentally or maliciously got access to your production database and dropped all the tables? There are a whole lot of people who rely on the company’s continued existence to feed themselves and their children.
Logins: I worked on a system a while ago that was essentially an SSO system for citizens to connect to services within our provincial government. Within that system there were a number of pretty mundane services but also a few that could have catastrophic consequences if the information was accessed by unauthorized individuals. Simple example: social services. If you’re a (newly) single mother who has just taken her children and left her abusive husband, access to the social services portal could give your abuser access to the address of the shelter you’re staying at and allow them to find you and harm you.
Shopify/Stripe/Paypal: there are a ton of businesses who rely on these services for their day-to-day income. How long could you keep the doors open if, say, your Stripe account stopped working because some bug wrote a bad value to a database table and completely prevented payments from coming through. Even worse, maybe it’s a bug that does allow you to collect payments but prevents you from accessing the money from those payments. Now you’ve sold your inventory but the money you need to buy more inventory and pay your employees is stuck in purgatory.
Photos app: on iOS there’s the ability to stuff photos into a Hidden folder that can only be unlocked with Face ID, not just your passcode. Going back to the abused mother scenario… abusive husband sneakily looks through his wife’s phone, does some kind of bypass on the Hidden Photos feature, and discovers that she’s been taking photos of the bruises to use as evidence.
LinkedIn: accidentally revealing on your public timeline that you’re considering looking for new employment and losing your job as a result.
Facebook/Twitter/Signal/etc: all kinds of negative potential outcomes if there’s any kind of data leak. For better or worse people engage in all kinds of conversations and activities that could be perfectly legal and/or/ethical but can have disastrously bad consequences if they’re shared publicly.
These are all “regular” types of software that people don’t specifically consider to be “safety-critical”. When you start looking at software that is specifically designed for vulnerable populations (e.g. Grindr), the consequences show up even quicker.
The safety continuum is interesting to software because it makes a point that I think is often under-looked - being too rigorous can lead to the overall system being less safe because important safety improvements are delayed or blocked. The graph on page 4 is the key point.
You could consider this when deploying new commits. If your tests are too onerous, it might prevent new code that might improve the stability of the system.
I think the “QL” part in GraphQL is misleading, it’s more of a way for a frontend component to declare what data they need in a way that can be composed, so that a parent component can fetch data for a tree of components upfront (avoiding waterfalls) while also maintaining the abstraction boundary between child and parent components and keep the child component’s data needs colocated with it.
To do that you basically just need a way to say “I need these fields from this type to render”; otherwise it’s pretty orthogonal to SQL and so forth. GraphQL doesn’t inherently have an equivalent to WHERE, GROUP BY, LIMIT, etc. Though there are conventions (like Relay’s connections spec for automatic pagination).
My take is it solves a Conway’s Law problem. Frontenders don’t know what data they need until they know, but they don’t feel empowered to ask for new endpoints. Using GraphQL means they can just write a new query and then the BE team can react after dev ops tells them the query has terrible performance or whatever.
GraphQL is just a declarative syntax to force a server to build a viewmodel for you.
I roughly agree and I think it can be good at that. GraphQL has flaws, and I wouldn’t turn to it for most projects, but I understand the situations where it has advantages.
I see this sentiment a lot. I personally appreciated the why of GraphQL after I spent more time understanding Ent, Metas “executable schema”. It’s worth poking around the blog posts for an open source version. Ent is an extremely expressive ORM that encodes a full graph of all of Metas data and properties (like PII, auth). GraphQL is just a way of querying/mutating that graph from networked clients. AFAICT Meta engineers don’t actually write GraphQL schemas -it is just generated from the Ent schema. The benefit of Ent over ANSI SQL is its expressiveness - Meta can encode business specific logic and have it enforced (and introspected) by all clients.
Last I checked (which has been a couple years; I’m not claiming the following is up to date), GraphQL didn’t actually join anything; you had to plumb everything into GraphQL yourself or use some middleware that can reflect over your postgres schema and configure GraphQL appropriately.
I care much less about the syntax and more about the amount of work I have to do to get something working.
GraphQL doesn’t “do” anything. Resolvers do. So either you use a custom resolver or you use something that provides resolvers automatically, but from the GraphQL user’s perspective joins are just {
you can build a robust GraphQL API by rewriting incoming queries into non-redundant ground-typed normal form, computing the expected result size in polynomial time, and then proceeding to execute the query only if the expected size is below an acceptable threshold.
I.e., you can inspect an incoming query and decide on whether to execute it instead of having to timeout queries that are too expensive in (execution) time or space.
I wonder whether running an end-to-end test suite before forking would warm the memory enough to show similar results with traditional forking app servers like unicorn. Shopify probably has enough data to tailor a warming test suite to cover most if not all code paths and not take forever.
But this would be quite impractical, as you’d very significantly slow down rollout of a new version, and fast deploys are really key in incident management among other things.
Maintaining such a “warmup” suite would also be quite a pain.
This is also speculative, but a test suite has lots of potential to cover code paths infrequently seen in production, plus there’s the resource use of the test code itself.
When you take this through to it’s logical conclusion you arrive at PGO. Because the best results likely come from measuring how often certain code paths are executed in production. We just need the developers of ruby to come up with a way to actually feed that data to the jit.
There’s another approach that I think is under-utilized in the industry - use real dependencies but run your tests against both the change and the last-known-good commit at the same time[^1]. If the LKG commit fails then you can chalk up it up to an external dependency failing. This obviously doesn’t fully exonerate the change, but in many scenarios that might be OK (or at least just significantly improves debug times). I would love to see a test framework with this built in.
[^1]: There are a few tricky things to consider (resource isolation etc.) but it’s not impossible.
I’m glad this was posted, because John Gruber has such different software values than I do. He seems to think of app development as being akin to making films (he even has a Kubrick quote), where meticulousness, look-and-feel, and polish matter much more than utility. He judges other pieces of software the way a filmmaker judges other films – he’s looking for artistry. But I view software as a utility first, and artwork second. And especially so for software running daily on my pocket computer (smartphone).
Meanwhile, many of my core software values don’t get a mention from him. Like the fact that there is way more open source software for Android than for iOS, and this goes down to every layer. Or, the fact that Android’s developer toolchain is entirely x-platform, allowing developers to tweak and modify software regardless of what desktop operating system they use.
I love Apple’s design values. When I have my design cap on, there’s a flow of admiration in the direction of macOS and iOS. And I even participate in the Apple ecosystem a little, with a Mac Mini & iPad. But my daily developer workstation is Linux, and my daily phone is Android. Thinkpad X1C and Pixel 7, because I do care about well-designed utility.
And both have f/oss software, programmability, and utility as their core values, aligned with mine. Thus, for me, and for many like me, that’s the show.
Now… when I’m recommending unfussy hardware/software for my non-techie friends & family? Sure, it’s the Macbook Air and iPhone, then. But I’m really glad a choice exists on the market for people like me, and I’m not sure what value there is in bashing the other side just because it doesn’t share your values.
The conclusion you don’t state, and perhaps don’t draw, is “the iphone apps that focus on look-and-feel are less functional than the android apps that don’t”. I certainly don’t draw that conclusion.
Look and feel matters for functionality. Those of you who haven’t read Jef Raskin’s book should read it, particularly chapters 2-4. One example: How many per cent of the touches/gestures hit and act on an item that wasn’t there yet when the user’s brain decided to act? This is easily measured with user testing, videos and questions, and one of the chief ways to reduce the number is to add slick little animations and transitions, so that touch targets don’t appear suddently, but rather slide in, grow, shrink in ways that the brain use.
Yes, I don’t draw that conclusion either. I think iOS and macOS apps are perfectly functional – and sometimes moreso than Android or Linux counterparts. But I don’t think John Gruber was treating good design as being in service of function. He was treating good design as a showcase of craft and artistry. (Perhaps even of commercial ambition, as he derides the Android Mastodon projects as “hobby projects”, while praising the iOS “commercial” ones.)
100% agree with you that Jef Raskin has some great thoughts on the utility of good design (many of which could benefit the f/oss world). There was some interesting work in this direction a few years back in the Linux desktop world by the (now defunct) non-profit Yorba.
Gruber is solidly from the background of Mac indie apps like Panic’s stuff, which place a premium on design and functionality but are also vehicles for sustaining small businesses.
That which we do is follow rules of thumb. We don’t reason from first principles, even when those first principles are important to us.
Our real goal is to build applications and services that serve the users well, which includes being low on frustration. Being low on errors and frustration is… being pleasant to use, which ends up being some rules of thumbs about animations and general slickness.
You may be interested in the work of Richard Sapper. He was the original designer of the first black Thinkpad 700c. He kind of embodies an alternative to the Deiter Rams school of design (which Apple follows closely) where every device is very solutions-oriented.
Facebook hired a bunch of googlers who liked Blaze (Google’s internal version of Bazel). Because blaze wasn’t open source at the time, they wrote a clone called buck.
I was out of Bazel by the fact that it depends on both Java and Python. A rust reimplementation that produces a statically linked binary for the build tool sounds attractive.
I hadn’t realized that in Smalltalk-72 each object parsed incoming messages. Every object had its own syntax. Ingalls cites performance as an issue then, but perhaps the idea is worth revisiting.
Smalltalk-72 - in contrast to all later Smalltalks - had indeed true message passing. That’s what Kay is usually referring to; it was his language design. The Smalltalk we know today, starting with Smalltalk-74, was invented by Ingalls and had little in common with Smalltak-72. Smalltalk-74 and later have virtual methods instead of message passing; but performance was still an issue.
Hey fun to see Sammy’s CPU on here. If anyone wants to hop on and look at it, connect to mc.openredstone.org with a Minecraft 1.17.1 client. Run /build then /warp CHUNGUS2 to warp to it.
The Open Redstone Engineers server (https://openredstone.org/) is a community of nerds who use Minecraft as our digital logic simulator of choice, and we spend most of our time on there designing and implementing CPUs. I and a few others started it in 2013 and it’s still going strong (though other people at the helm these days). This CPU was made by a member called sammyuri who’s online every now and then.
I don’t think there’s a lot Minecraft proper can or should do. The main problem is that everything in the game takes 1/10th of a second (what we call a redstone tick) to update – so that means a CPU like this has 10 ticks per clock cycle. (For reference, something like an AND gate requires two ticks, so 2/10ths of a second.) There are things Minecraft could do to support more complex circuits without the tick rate dropping further, but ORE already has a lot of server-side plug-ins to improve performance in that respect.
However, another member of ORE, StackDoubleFlow, has been working on a re-implementation of the Minecraft server software: https://github.com/MCHPR/MCHPRS – This reimplementation is written in Rust, and the whole point is to execute redstone circuits at insane clock rates. I would guess that something like this 1Hz CPU could execute at at least tens or hundreds of kHz on MCHPRS.
I think MCHPRS is the next step in cool Minecraft CPUs. I’m working on a CPU with a 16-bit address space in order to be able to write some seriously interesting complex programs. Someone else on ORE is working on a complete RISC-V implementation, including all the ISA extensions necessary to get Linux running on it. The promise of being able to actually do something with the machines is what has gotten me back into making redstone CPUs lately.
(Also, maybe, eventually, there may come a re-implementation of the client. I think we may eventually have re-implemented ourselves out of Microsoft’s grip. Watch this space.)
It means infra/tools ops people migrating between the companies and bringing their favorite tools with them.
Which has nothing to with whether it’s a good choice or not. Enterprise companies are notorious in copying each other approaches, so whichever gets popular at any point tends to be entrenched for some years. “Google does it” is always going to win against solitary voices saying “but it’s complicated, and there’s a better way”.
I work in an enterprise, a pretty large one and all I see is maven and some gradle. No bazel in sight. I also have been following the project a bit for year, but never met anyone who used it (outside Google, but they have the original called blaze IIRC)
Hey, let me make a list of enterprise who is using Bazel and then share it with Lobste.rs
There is definitely an upward trend in adoption of bazel in the last 3 years, so much that I don’t think I can adequately dropping all the names in 1 go. But if you must know, I will make a small list with some big names here who have publicly said that they are adopting bazel (not just 1-2 projects):
Google
Twitter (Java, Scala)
VMWare (Erlang, C/C++)
Adobe Cloud (Go / Docker / K8s)
Tinder (Kotlin / Java)
Pinterest (Java, Go, Python, NodeJS)
Dropbox (C, Python, Go)
Huawei (C/C++)
Lyft (iOS)
Uber (Golang)
Grab (Android)
Stripe (Ruby, Python)
Apple (Go, Java)
Robinhood
Wix
SpaceX
TwoSigma
Etsy
NVDIA (C/C++, CUDA, Go, Scala)
So you can see that a large portion of FAANGMULA and equivalents unicorns are adopting Bazel. Among them, Facebook is rebuilding Bucks 2.0 and has snatched some key hires from Bazel/Build community in the past years. Microsoft MSBuild is also adopting Bazel’s RBE spec. There are also bigger companies / startups who are experimenting with Bazel on 1 or 2 smaller projects:
Redhat
Gitlab
Brave
BMW
LinkedIn
Tweag
There are a number of startups / consulting companies in this space, some include members of the Blaze team leaving Google, to address the upcoming market demand:
BuildBuddy
EngFlow
FlareBuild
Aspect Dev
OasisDigital
The above are not an exhaustive list, it’s what in my head after 15 mins of writing this post.
Google people are trying to push Bazel into everything that they touch. It’s a fine build system if you can guarantee that you will only ever want to ship things on one of the three or four platforms that Google thinks are important. Since ‘Enterprise’ is often a synonym for ‘expensive lock-in’, I don’t have any reason to doubt the original claim.
I’m an ex developer of factorio, I have to ask: have you actually used this on a real candidate? Not sure how I would respond :D
I specifically remember great anger over my building a left hand drive train system during play testing (I’m Irish, we use left hand drive, most other devs are from mainland Europe, so use right hand drive).
I’m French, and my train systems are also left hand drive, for two reasons:
France’s trains also use left hand drive (even though the cars use right hand drive).
It places the signals in the insides of the tracks.
The first reason is pedantically subjective, but I believe placing signals inside of the tracks has real, technical value in some cases. And it’s more elegant. In any case, I still screw it up sometimes and forget that my own system is left hand drive…
The differences are fairly important - Phoenix has long lived stateful processes on the server and only transmits minimal state diffs (not HTML) to be interpreted in the client.
I am 100% over versioning. I have never seen an implementation that doesn’t suck. It’s miserable. Something is fundamentally wrong with the whole model, whatever methodology you use for tagging won’t fix that.
There could be different ways:
Google has run decently internally by building everything from HEAD. It’s not easy, and it requires a monorepo, but it does work. Could this work in the real world? Probably not. But what if you say “GitHub is a monorepo”? What if when the dependency author uploads a breaking change, GitHub can say who they broke and how it broke, prompt the dependency author to document what the remediation for that pattern of breakage is, and just let people be broken until they upgrade? Maybe this is pushed to per-language registries like crates.io or the Go proxy.
Unison tries to sidestep versioning entirely at the language level.
Stop trying to meld dependencies together across packages. Every package and its dependencies are treated separately, and binaries just include every version that is depended on. Hard drive size is a trivial concern, binary sizes when you’re building binaries into Docker containers means the image size almost certainly dominates.
I can’t wait for some of the ideas from Unison to permeate into more mainstream ecosystems. Lots of great ideas (globally accessible CAS, AST storage etc.) stuck behind a Haskell-like syntax.
I sort of agree because I don’t think there’s a perfect versioning system, but I think semver2 may be as good as it gets.
I like it because it’s more functional than the marketing driven “versions don’t matter, we’ll just call it version 2.0 to sell more” and all the alternatives get into too much time spent on perfecting versioning systems to diminishing returns.
I use it just so we have something, it saves time from deciding what to do, and it helps denote drafts or breaking changes. I use it even for stupid stuff like the “enterprise policy on bathroom breaks.” If it’s version 0.4.77 then it’s still in progress and could change any time. If it’s 1.1.16 then I mean it’s probably approved by someone. If I use 1.1.16 and see version 2.0 then it probably means I should read it because now it means I can only go to the bathroom on even hours or something that disrupts or may disrupt me.
I’ve been addicted to these podcasts lately. I started with the Johnathan Blow episode, but I’ve been working my way up from the bottom. Learning about both computing and the people involved has been really informative and entertaining, and that’s for someone who has never subscribed to a podcast series before. Bryan Cantrill is a surprisingly adept interviewer.
I’ve been telling my family for several years about the impending collapse of the gigantic house of cards of modern software based on what I’ve seen. They don’t believe me.
The #1 thing we need to do is to do is apprentice and case-study based training of developers. Start training developers using case studies with real programs instead of just abstract ideas like “encapsulation” and having them write from scratch without having seen what production software looks like. Literate programming book such as Pharr and Humphreys’ amazing “Physically based rendering” are good steps in this direction.
I really wished my college days were spent more on building and less on learning about polymorphism and encapsulation.
That said, the author misses the point that we are in the middle of a huge boom where entire industries are just now looking around and saying, “How can we make our business more efficient with software?” Of course software is ideally supposed to ship bug free, of course Catalina shouldn’t have bugs, but at the end of the day we live in a world where user growth and utility drives value, not code quality.
Century old industries are just now coming online and trying to integrate software into their business models, so they likely are either going to make low quality software that solves immediate needs. Not all companies view software as a revenue center.
For most companies in the world software is just a way to lower costs. Not a money maker. Many of us are biased by the fact we work in tech and work on software products/projects that are money makers. Some of the companies in the post are giant tech companies.
Imagine the total lines of code count at any of the companies mentioned. It’s easily in the hundreds of millions or even billions. Of course there are examples of bad code!
I wonder if folks would have this same reaction if a developer license was $10 a year? Is it a purely financial decision or is it just that they’re being asked to quantify their hobby at all?
Own a mac (recent enough to run a supported OS) in order to run the signing tools,
Spend your hobby time packaging your work for apple to review (rather than just distributing a zipfile which extracts the app, you need the whole signing workflow on each release),
Send apple your work for review, and be subject to arbitrary rejection (for the app store).
To this first-world-living, employed, healthy programmer, the $100/year is an irrelevance. Stealing my hobby time to make me jump through banal hoops is not (to be clear: I would be more OK with doing this if it weren’t such a hassle; signature verification isn’t without its merits).
I have quite a few apps that will stop working in Catalina. I just don’t care enough; this MacBook Air will go in the collection room when 10.14 is no longer supported.
Some good rants in there. Particularly enjoyed the Candela and Hertz ones. Plenty of small stuff I wouldn’t have thought about as well, e.g. flour measurements:
I loved Alan’s Spinal Tap reference while
rantingdiscussing the “international prototype”:Yeah, some people preach the perfect rationality of SI so hard that you’d think they must believe that a cube one meter on a side has a volume of one liter, and if you fill it with water (at STP) that water will have a mass of one gram.
This sounds like a person made of a stere of straw.
The current system of Meter - Kilogram - Second is just an historical accident. The British used to use cgs (centimeter - gram - second) while the French used MTS (metre - tonne - second).
https://en.wikipedia.org/wiki/MKS_units#History
Having the prototype being a kilogram is also more practical than one weighing just a gram or one weighing a ton…
It isn’t just a historical accident: the original metric prototypes were the mètre des archives and the kilogramme des archives made in 1799, and there’s a direct line from them via the 1880s replacement prototypes to the current SI. There were deviations like cgs and MTS, but all calibration of tools and instruments had a metrological trace back to the kilogramme.
So most of the blame goes to the savants of the académie des sciences who made a deliberate choice that their unprefixed units would be the metre (1/10000 quadrant of latitude), litre (1/1000 m^3), and gramme (mass of 1/1000 litre of water).
Yeah it’s weird. The metre and the yard are of similar dimensions, and I don’t know how the litre and contemporaneous volume definitions differ. Why is the gram so much smaller?
Part of the rationale for the metric system at the time was to harmonize/eliminate regional differences of weights and measures in France. Maybe using the smaller unit made it easier to define existing weights in terms of numbers closer to integer values instead of fractional (compare the modern pound which is 0.4536 kg or 453.6 g).
BTW the kg is not the only “irrational” unit, almost no-one uses the are as a measure of area, it’s all hectares…
I don’t know if it’s just me, but I find Typescript written with Effect somewhat hard to grok.
It sounds like an interesting project but when I look at the Without Effect and With Effect code samples on https://effect.website, my immediate reaction is that I’ll take the Without Effect version.
From this post, it seems somewhat nice that the final “effect” of a chain of actions is hoisted up to the top and you can see what it returns if it succeeds or fails.
But those chains of pipes… That doesn’t seem to be the most readable to me.
You might be interested in effection which tries to accomplish similar goals but look like vanilla JS: https://frontside.com/effection/
There’s also https://starfx.bower.sh which builds off of it and is used in the FE.
Very interesting!
My ears definitely perk up at the mention of structured concurrency (I wrote a blog post about it in Rust).
From looking through the website a bit, I was missing some of the “why” for this approach though. This blog post explains it more, but I’m still not sure how big of an issue this is in TS/JS land: https://frontside.com/blog/2023-12-11-await-event-horizon/
Nevertheless, it does seem nice that it seems to be using slightly more built-in constructs: https://frontside.com/effection/docs/async-rosetta-stone
Great insight, I tried to answer that question here: https://bower.sh/why-structured-concurrency
For me, the problem reduces down to async flow control and structured concurrency is a fantastic way to manage it. This is why structured concurrency is such a great tool for TS since the node/browser is single-threaded and requires strong concurrent tooling. It’s a great fit.
That’s something that would need to be fixed on the language level. ts-effect can’t do much here.
I agree. The pitch of “the missing standard library for TypeScript” is extremely off-putting. I can imagine balls of spaghetti code because Effect is neither a standard nor a language. That positioning is going to mean that everybody invents best practices and it’ll be used either too much or too little.
I’d love to see an effect system in TS but it needs to be language level for it to be practical.
Yeah, I could barely get something written. No chance I’d get anybody else to read or write this stuff.
For the last few months, I’ve been obsessed with Decker and Lil. It’s just such a beautiful little ecosystem for hacking together reasonably decent apps and scripts in no time at all.
What kinds of things have you been building with it?
The last 2 days, I’ve been moving a bunch of spreadsheets that I used for figuring out marathon training schedules.
But, I’ve also got various Lil scripts that generate weather report web pages via cron every few hours, an RSS reader, a bug tracker, a static site generator, a half-assed web browser…a bunch of stuff that I wouldn’t dare show the public, but that are fun to hack around on. Some day I’ll get around to making my Eton Wall Game video game that I have been promising myself I will make for years. I envision it as interactive fiction, but maybe it’ll be a bad pong adaptation. Who knows?
So using Lil outside of the decker context a lot?
Both. I generally try to build everything as a Decker deck and then write a Lil script to load the deck and send the events to make things happen.
So you drive the deck from the outside using a lil script in order to enable I/O?
The io happens inside the deck. There’s a new “danger” interface that enables shell[] and readfile[]
My wife is officially overdue for our second child.
Definitely keeping me up.
Good luck and happy Mother’s Day to your wife!
…and will be for the foreseeable future…
Enjoy!
Congratulations 🎊
From another dad of 2 kids, rooting for you guys!!
As a former NICU father, I congratulate you on making it to overdue and wish you and your wife a safe and quick birth!
Congrats! Waiting for my first now, could happen any day now. Trying to not do anything at work
congratz!!
congrats!
One fun consequence of being able to run every hash in parallel is that you could route traffic to each commit based on a multi-arm bandit optimization. That would mean highly efficient canary deploys for free.
Depending on your traffic volume it could also make most A/B tests (where the hypothesis is “does not decrease metric”) moot. Fewer conditionals in your code base by virtue of your entire code base being under experiment.
Could you say more about the canary deploys idea?
Yes - in fact, because the instrumentation is so much more thorough, every change can be seen as an A/B test, with its own bucket of metrics!
As you gain confidence in each commit you can ramp traffic to it. The “canary” size would be related to the regret of your algorithm.
The canary would be efficient because routing decisions could happen immediately rather than in some time-period like most canary setups today. If a commit ever serves a single 500 there’s no reason to serve it anymore! The dev workflow would be amazing because there would be virtually 0 cost to just trying things and testing against prod.
Can you please comment as to how this is directly applicable to software? Most of us do not work on safety critical stuff.
For the last 5 years or so I’ve been working on safety-critical and safety-critical-adjacent software and hardware (UAV payloads). As a result, I’ve had an interesting mental shift that definitely has me seeing safety assessments and thinking in other contexts.
This is all kind of an off-the-cuff brain dump here. We usually think of safety-critical systems as “systems that will kill or severely injure people if they fail” and those kinds of systems definitely do deserve a severe degree of analysis and scrutiny, but overall it really is a spectrum. A couple of examples off the top of my head (many coming from looking at the home screen on my phone):
Backups: how robust is your company’s database backup infrastructure? Would the business survive If someone accidentally or maliciously got access to your production database and dropped all the tables? There are a whole lot of people who rely on the company’s continued existence to feed themselves and their children.
Logins: I worked on a system a while ago that was essentially an SSO system for citizens to connect to services within our provincial government. Within that system there were a number of pretty mundane services but also a few that could have catastrophic consequences if the information was accessed by unauthorized individuals. Simple example: social services. If you’re a (newly) single mother who has just taken her children and left her abusive husband, access to the social services portal could give your abuser access to the address of the shelter you’re staying at and allow them to find you and harm you.
Shopify/Stripe/Paypal: there are a ton of businesses who rely on these services for their day-to-day income. How long could you keep the doors open if, say, your Stripe account stopped working because some bug wrote a bad value to a database table and completely prevented payments from coming through. Even worse, maybe it’s a bug that does allow you to collect payments but prevents you from accessing the money from those payments. Now you’ve sold your inventory but the money you need to buy more inventory and pay your employees is stuck in purgatory.
Photos app: on iOS there’s the ability to stuff photos into a Hidden folder that can only be unlocked with Face ID, not just your passcode. Going back to the abused mother scenario… abusive husband sneakily looks through his wife’s phone, does some kind of bypass on the Hidden Photos feature, and discovers that she’s been taking photos of the bruises to use as evidence.
LinkedIn: accidentally revealing on your public timeline that you’re considering looking for new employment and losing your job as a result.
Facebook/Twitter/Signal/etc: all kinds of negative potential outcomes if there’s any kind of data leak. For better or worse people engage in all kinds of conversations and activities that could be perfectly legal and/or/ethical but can have disastrously bad consequences if they’re shared publicly.
These are all “regular” types of software that people don’t specifically consider to be “safety-critical”. When you start looking at software that is specifically designed for vulnerable populations (e.g. Grindr), the consequences show up even quicker.
I think this is a fantastic list and if you ever flesh it out to a blog post, I’ll share it with every software person I know.
The safety continuum is interesting to software because it makes a point that I think is often under-looked - being too rigorous can lead to the overall system being less safe because important safety improvements are delayed or blocked. The graph on page 4 is the key point.
You could consider this when deploying new commits. If your tests are too onerous, it might prevent new code that might improve the stability of the system.
I still wonder why GraphQL exists. It just seems to reinvent parts of SQL in curly braces syntax?
I think the “QL” part in GraphQL is misleading, it’s more of a way for a frontend component to declare what data they need in a way that can be composed, so that a parent component can fetch data for a tree of components upfront (avoiding waterfalls) while also maintaining the abstraction boundary between child and parent components and keep the child component’s data needs colocated with it.
To do that you basically just need a way to say “I need these fields from this type to render”; otherwise it’s pretty orthogonal to SQL and so forth. GraphQL doesn’t inherently have an equivalent to WHERE, GROUP BY, LIMIT, etc. Though there are conventions (like Relay’s connections spec for automatic pagination).
I’d say it’s better than a random half-specified subset of SQL. GraphQL also seem to provide better access control than the approach taken in OP.
My take is it solves a Conway’s Law problem. Frontenders don’t know what data they need until they know, but they don’t feel empowered to ask for new endpoints. Using GraphQL means they can just write a new query and then the BE team can react after dev ops tells them the query has terrible performance or whatever.
Or they feel overly empowered and you end up with five dozen subtly different god endpoints.
I forget where I saved this quote from, but:
I roughly agree and I think it can be good at that. GraphQL has flaws, and I wouldn’t turn to it for most projects, but I understand the situations where it has advantages.
I see this sentiment a lot. I personally appreciated the why of GraphQL after I spent more time understanding Ent, Metas “executable schema”. It’s worth poking around the blog posts for an open source version. Ent is an extremely expressive ORM that encodes a full graph of all of Metas data and properties (like PII, auth). GraphQL is just a way of querying/mutating that graph from networked clients. AFAICT Meta engineers don’t actually write GraphQL schemas -it is just generated from the Ent schema. The benefit of Ent over ANSI SQL is its expressiveness - Meta can encode business specific logic and have it enforced (and introspected) by all clients.
Brace syntax is really nice. People struggling with JOIN’ing data together, but in Graphql it’s a trivial
{.Last I checked (which has been a couple years; I’m not claiming the following is up to date), GraphQL didn’t actually join anything; you had to plumb everything into GraphQL yourself or use some middleware that can reflect over your postgres schema and configure GraphQL appropriately.
I care much less about the syntax and more about the amount of work I have to do to get something working.
GraphQL doesn’t “do” anything. Resolvers do. So either you use a custom resolver or you use something that provides resolvers automatically, but from the GraphQL user’s perspective joins are just
{rummages around in old notes … ah, here:
(https://blog.acolyer.org/2018/05/21/semantics-and-complexity-of-graphql/, discussing https://dl.acm.org/citation.cfm?id=3186014)
I.e., you can inspect an incoming query and decide on whether to execute it instead of having to timeout queries that are too expensive in (execution) time or space.
The answer is: Marketing.
I do agree that it is unfortunate that such things sneak in areas tha should be left for engineering.
I wonder whether running an end-to-end test suite before forking would warm the memory enough to show similar results with traditional forking app servers like unicorn. Shopify probably has enough data to tailor a warming test suite to cover most if not all code paths and not take forever.
Eric Wong suggested something similar when I submitted the first version of reforking upstream: https://yhbt.net/unicorn-public/aecd9142-94cf-b195-34f3-bea4870ed9c8@shopify.com/T/#m30f8059af3b0d7f2dbcbbca12aff261b0cb9e1fb
But this would be quite impractical, as you’d very significantly slow down rollout of a new version, and fast deploys are really key in incident management among other things.
Maintaining such a “warmup” suite would also be quite a pain.
This is also speculative, but a test suite has lots of potential to cover code paths infrequently seen in production, plus there’s the resource use of the test code itself.
When you take this through to it’s logical conclusion you arrive at PGO. Because the best results likely come from measuring how often certain code paths are executed in production. We just need the developers of ruby to come up with a way to actually feed that data to the jit.
PGO is Profile Guided Optimization for folks like me who didn’t know.
There’s another approach that I think is under-utilized in the industry - use real dependencies but run your tests against both the change and the last-known-good commit at the same time[^1]. If the LKG commit fails then you can chalk up it up to an external dependency failing. This obviously doesn’t fully exonerate the change, but in many scenarios that might be OK (or at least just significantly improves debug times). I would love to see a test framework with this built in.
[^1]: There are a few tricky things to consider (resource isolation etc.) but it’s not impossible.
I’m glad this was posted, because John Gruber has such different software values than I do. He seems to think of app development as being akin to making films (he even has a Kubrick quote), where meticulousness, look-and-feel, and polish matter much more than utility. He judges other pieces of software the way a filmmaker judges other films – he’s looking for artistry. But I view software as a utility first, and artwork second. And especially so for software running daily on my pocket computer (smartphone).
Meanwhile, many of my core software values don’t get a mention from him. Like the fact that there is way more open source software for Android than for iOS, and this goes down to every layer. Or, the fact that Android’s developer toolchain is entirely x-platform, allowing developers to tweak and modify software regardless of what desktop operating system they use.
I love Apple’s design values. When I have my design cap on, there’s a flow of admiration in the direction of macOS and iOS. And I even participate in the Apple ecosystem a little, with a Mac Mini & iPad. But my daily developer workstation is Linux, and my daily phone is Android. Thinkpad X1C and Pixel 7, because I do care about well-designed utility.
And both have f/oss software, programmability, and utility as their core values, aligned with mine. Thus, for me, and for many like me, that’s the show.
Now… when I’m recommending unfussy hardware/software for my non-techie friends & family? Sure, it’s the Macbook Air and iPhone, then. But I’m really glad a choice exists on the market for people like me, and I’m not sure what value there is in bashing the other side just because it doesn’t share your values.
The conclusion you don’t state, and perhaps don’t draw, is “the iphone apps that focus on look-and-feel are less functional than the android apps that don’t”. I certainly don’t draw that conclusion.
Look and feel matters for functionality. Those of you who haven’t read Jef Raskin’s book should read it, particularly chapters 2-4. One example: How many per cent of the touches/gestures hit and act on an item that wasn’t there yet when the user’s brain decided to act? This is easily measured with user testing, videos and questions, and one of the chief ways to reduce the number is to add slick little animations and transitions, so that touch targets don’t appear suddently, but rather slide in, grow, shrink in ways that the brain use.
Yes, I don’t draw that conclusion either. I think iOS and macOS apps are perfectly functional – and sometimes moreso than Android or Linux counterparts. But I don’t think John Gruber was treating good design as being in service of function. He was treating good design as a showcase of craft and artistry. (Perhaps even of commercial ambition, as he derides the Android Mastodon projects as “hobby projects”, while praising the iOS “commercial” ones.)
100% agree with you that Jef Raskin has some great thoughts on the utility of good design (many of which could benefit the f/oss world). There was some interesting work in this direction a few years back in the Linux desktop world by the (now defunct) non-profit Yorba.
Gruber is solidly from the background of Mac indie apps like Panic’s stuff, which place a premium on design and functionality but are also vehicles for sustaining small businesses.
Try sending him mail. Ask “is a low error frequency a sign of good craftsmanship?”
I can guess his answer.
I’m going to post my own answer.
That which we do is follow rules of thumb. We don’t reason from first principles, even when those first principles are important to us.
Our real goal is to build applications and services that serve the users well, which includes being low on frustration. Being low on errors and frustration is… being pleasant to use, which ends up being some rules of thumbs about animations and general slickness.
His very first example, Ice Cubes, is open source.
You may be interested in the work of Richard Sapper. He was the original designer of the first black Thinkpad 700c. He kind of embodies an alternative to the Deiter Rams school of design (which Apple follows closely) where every device is very solutions-oriented.
I failed to understand what is Buck exactly - is it alternative to meson/bazel?
It’s worth reading the Buck2 explainer. It’s a really promising exploration of monadic build systems (ala. Shake, llbuild2) at Bazel scale.
Facebook hired a bunch of googlers who liked Blaze (Google’s internal version of Bazel). Because blaze wasn’t open source at the time, they wrote a clone called buck.
I was out of Bazel by the fact that it depends on both Java and Python. A rust reimplementation that produces a statically linked binary for the build tool sounds attractive.
The subset of Python supported by Bazel (Starlark) does not depend on CPython, it’s interpreted by Bazel itself.
A Python interpreter was used historically but I believe the migration happened before Bazel became open sourced.
The installation instructions say that it depends on:
I hadn’t realized that in Smalltalk-72 each object parsed incoming messages. Every object had its own syntax. Ingalls cites performance as an issue then, but perhaps the idea is worth revisiting.
Also, here’s a link to Schorre’s META II paper that he mentions: https://doi.org/10.1145/800257.808896
Smalltalk-72 - in contrast to all later Smalltalks - had indeed true message passing. That’s what Kay is usually referring to; it was his language design. The Smalltalk we know today, starting with Smalltalk-74, was invented by Ingalls and had little in common with Smalltak-72. Smalltalk-74 and later have virtual methods instead of message passing; but performance was still an issue.
Each object having its own syntax turned out to be an almost bigger problem than performance. And I am not sure about the “almost”.
Hey fun to see Sammy’s CPU on here. If anyone wants to hop on and look at it, connect to mc.openredstone.org with a Minecraft 1.17.1 client. Run
/buildthen/warp CHUNGUS2to warp to it.The Open Redstone Engineers server (https://openredstone.org/) is a community of nerds who use Minecraft as our digital logic simulator of choice, and we spend most of our time on there designing and implementing CPUs. I and a few others started it in 2013 and it’s still going strong (though other people at the helm these days). This CPU was made by a member called sammyuri who’s online every now and then.
I didn’t expect to see ORE show up on lobste.rs.
after updating java, right? :)
updating java won’t help you much
(OT) Given your experience, what do you think Minecraft should change to improve performance of in-game CPUs like this?
I don’t think there’s a lot Minecraft proper can or should do. The main problem is that everything in the game takes 1/10th of a second (what we call a redstone tick) to update – so that means a CPU like this has 10 ticks per clock cycle. (For reference, something like an AND gate requires two ticks, so 2/10ths of a second.) There are things Minecraft could do to support more complex circuits without the tick rate dropping further, but ORE already has a lot of server-side plug-ins to improve performance in that respect.
However, another member of ORE, StackDoubleFlow, has been working on a re-implementation of the Minecraft server software: https://github.com/MCHPR/MCHPRS – This reimplementation is written in Rust, and the whole point is to execute redstone circuits at insane clock rates. I would guess that something like this 1Hz CPU could execute at at least tens or hundreds of kHz on MCHPRS.
I think MCHPRS is the next step in cool Minecraft CPUs. I’m working on a CPU with a 16-bit address space in order to be able to write some seriously interesting complex programs. Someone else on ORE is working on a complete RISC-V implementation, including all the ISA extensions necessary to get Linux running on it. The promise of being able to actually do something with the machines is what has gotten me back into making redstone CPUs lately.
(Also, maybe, eventually, there may come a re-implementation of the client. I think we may eventually have re-implemented ourselves out of Microsoft’s grip. Watch this space.)
I wasn’t asked but have you seen papermc ? https://github.com/PaperMC/Paper it does a lot right
The enterprise community is uniting around Bazel right now.
Citation needed! No seriously, which enterprise community is that supposed to be?
It means infra/tools ops people migrating between the companies and bringing their favorite tools with them.
Which has nothing to with whether it’s a good choice or not. Enterprise companies are notorious in copying each other approaches, so whichever gets popular at any point tends to be entrenched for some years. “Google does it” is always going to win against solitary voices saying “but it’s complicated, and there’s a better way”.
I work in an enterprise, a pretty large one and all I see is maven and some gradle. No bazel in sight. I also have been following the project a bit for year, but never met anyone who used it (outside Google, but they have the original called blaze IIRC)
Hey, let me make a list of enterprise who is using Bazel and then share it with Lobste.rs
There is definitely an upward trend in adoption of bazel in the last 3 years, so much that I don’t think I can adequately dropping all the names in 1 go. But if you must know, I will make a small list with some big names here who have publicly said that they are adopting bazel (not just 1-2 projects):
So you can see that a large portion of FAANGMULA and equivalents unicorns are adopting Bazel. Among them, Facebook is rebuilding Bucks 2.0 and has snatched some key hires from Bazel/Build community in the past years. Microsoft MSBuild is also adopting Bazel’s RBE spec. There are also bigger companies / startups who are experimenting with Bazel on 1 or 2 smaller projects:
There are a number of startups / consulting companies in this space, some include members of the Blaze team leaving Google, to address the upcoming market demand:
The above are not an exhaustive list, it’s what in my head after 15 mins of writing this post.
https://github.com/bazelbuild/bazel/search?q=blaze always makes me laugh.
Google people are trying to push Bazel into everything that they touch. It’s a fine build system if you can guarantee that you will only ever want to ship things on one of the three or four platforms that Google thinks are important. Since ‘Enterprise’ is often a synonym for ‘expensive lock-in’, I don’t have any reason to doubt the original claim.
Do you mean Google? Or anyone else?
(I’ve read that Bazel has been designed especially for building Google projects, on Google architecture, using Google style of source management)
Square.
As well as Twitter, Dropbox & Pinterest (all to varying degrees).
I’m an ex developer of factorio, I have to ask: have you actually used this on a real candidate? Not sure how I would respond :D
I specifically remember great anger over my building a left hand drive train system during play testing (I’m Irish, we use left hand drive, most other devs are from mainland Europe, so use right hand drive).
(OT but…) Thank you (and the rest of Wube) for a really fantastic game! I’ve and so many people I know have got so much value out of Factorio.
Trains and subways (but not trams) still drive on the left in Sweden (Sweden went over to RHS road traffic in 1967).
As in France, because IIRC, Britain built the train system there.
I’m French, and my train systems are also left hand drive, for two reasons:
The first reason is pedantically subjective, but I believe placing signals inside of the tracks has real, technical value in some cases. And it’s more elegant. In any case, I still screw it up sometimes and forget that my own system is left hand drive…
For what it’s worth, I believe that Elixir’s Phoenix framework uses a similar technique for LiveView.
The differences are fairly important - Phoenix has long lived stateful processes on the server and only transmits minimal state diffs (not HTML) to be interpreted in the client.
I am 100% over versioning. I have never seen an implementation that doesn’t suck. It’s miserable. Something is fundamentally wrong with the whole model, whatever methodology you use for tagging won’t fix that.
There could be different ways:
I can’t wait for some of the ideas from Unison to permeate into more mainstream ecosystems. Lots of great ideas (globally accessible CAS, AST storage etc.) stuck behind a Haskell-like syntax.
Compare-And-Swap? Content-Aware Scaling? Close Air Support? Computer Algebra System? Content-Addressable Storage?
Content-Addressable Storage. Check it out! https://www.unisonweb.org/
I sort of agree because I don’t think there’s a perfect versioning system, but I think semver2 may be as good as it gets.
I like it because it’s more functional than the marketing driven “versions don’t matter, we’ll just call it version 2.0 to sell more” and all the alternatives get into too much time spent on perfecting versioning systems to diminishing returns.
I use it just so we have something, it saves time from deciding what to do, and it helps denote drafts or breaking changes. I use it even for stupid stuff like the “enterprise policy on bathroom breaks.” If it’s version 0.4.77 then it’s still in progress and could change any time. If it’s 1.1.16 then I mean it’s probably approved by someone. If I use 1.1.16 and see version 2.0 then it probably means I should read it because now it means I can only go to the bathroom on even hours or something that disrupts or may disrupt me.
Ron Minnich’s interview with On The Metal is great too: https://oxide.computer/blog/on-the-metal-3-ron-minnich/
I’ve been addicted to these podcasts lately. I started with the Johnathan Blow episode, but I’ve been working my way up from the bottom. Learning about both computing and the people involved has been really informative and entertaining, and that’s for someone who has never subscribed to a podcast series before. Bryan Cantrill is a surprisingly adept interviewer.
Agreed! Great guests, great interviewers. Don’t miss out on the show notes, they’re usually packed with a lot more supporting material.
I’ve been telling my family for several years about the impending collapse of the gigantic house of cards of modern software based on what I’ve seen. They don’t believe me.
The #1 thing we need to do is to do is apprentice and case-study based training of developers. Start training developers using case studies with real programs instead of just abstract ideas like “encapsulation” and having them write from scratch without having seen what production software looks like. Literate programming book such as Pharr and Humphreys’ amazing “Physically based rendering” are good steps in this direction.
http://www.pbr-book.org for those interested in following the referral.
Could you elaborate on what you mean by “collapse”? How would you expect the experience of writing or using software to be different afterwards?
I really wished my college days were spent more on building and less on learning about polymorphism and encapsulation.
That said, the author misses the point that we are in the middle of a huge boom where entire industries are just now looking around and saying, “How can we make our business more efficient with software?” Of course software is ideally supposed to ship bug free, of course Catalina shouldn’t have bugs, but at the end of the day we live in a world where user growth and utility drives value, not code quality.
Century old industries are just now coming online and trying to integrate software into their business models, so they likely are either going to make low quality software that solves immediate needs. Not all companies view software as a revenue center.
For most companies in the world software is just a way to lower costs. Not a money maker. Many of us are biased by the fact we work in tech and work on software products/projects that are money makers. Some of the companies in the post are giant tech companies.
Imagine the total lines of code count at any of the companies mentioned. It’s easily in the hundreds of millions or even billions. Of course there are examples of bad code!
I wonder if folks would have this same reaction if a developer license was $10 a year? Is it a purely financial decision or is it just that they’re being asked to quantify their hobby at all?
It’s not just the developer license; you have to:
To this first-world-living, employed, healthy programmer, the $100/year is an irrelevance. Stealing my hobby time to make me jump through banal hoops is not (to be clear: I would be more OK with doing this if it weren’t such a hassle; signature verification isn’t without its merits).
Yes. I haven’t owned a Mac since 2011, but I’m getting requests for a small open source project I haven’t really worked on since 2012 to be updated.
It’s no great tragedy that I probably won’t ever update it for Catalina, but it is a bit of a shame.
I have quite a few apps that will stop working in Catalina. I just don’t care enough; this MacBook Air will go in the collection room when 10.14 is no longer supported.