Unlurker|Replay|About
The U.S. Ammo Shortage Is Worse Than You Think (wsj.com)
•
There was a RUSI paper at the start of the Russian invasion of Ukraine that identified this problem. The one area of munitions supply that was in good shape was 5.56mm, the "assault rifle" culture in the US means there are enough people plinking at targets to keep a good number of factories profitable.
•
https://archive.ph/XQINK
•
Why can't we just import munitions and medicines from overseas as usual? It's inefficient to manufacture in the US because of all the regulations to prevent occupational hazards and environmental destruction, the minimum wage and unions, the high price of medical care, and having to transport all the input materials to a US factory.
•
Hopefully your question is sarcasm, as it should be obvious why this is a terrible idea on many fronts. In case it isn't, for starters, especially given the way the world seems to be changing these days, if you put all of your critical supplies in the hands of another nation, especially an adversary like China, you basically are at their beck and call when things get ugly. Even non-advesary states can either have regime change or just not want to deal with you, and all of a sudden everything is completely out of your control. Others basically own you at that point, which is obviously unacceptable from a defense or critical logistics standpoint. On a whole other level, it's incredibly immoral and stupid that we're ok with externalizing problems that labor and environmental standards protect. If you wouldn't accept having your kin or friends work in the sort of conditions you see in many exploitative "cheap labor" centers overseas so much so that it's codified in law, why is it OK to just pawn it off on another nation's people? If you wouldn't accept the environmental damage that other countries seem willing to inflict, why is it suddenly ok when laundered as free trade, especially given how concerned we are with the global reach of environmental problems. If there were ever an application for tariffs that made sense it would be to ding the shit out of products and services that come from states that don't meet minimum levels of labor and environmental law. The only reason we don't do this is that we're addicted to cheap shit and can't think more than maybe a year ahead.
•
Kind of a nothing article. I think the title hinges on this once sentence: > The U.S. lacks enough munitions to support its war plans if a protracted conflict with China, Russia or North Korea arises. But no actual amounts or anything mentioned, just supposing. Not that I expected anything more from WSJ.
•
Magazine depth is a matter of national security, you won't get close to the "actual amount" even with an insider leak.
•
We need a military that is well-equipped but also cost-conscious in how they are provisioned. The Military Industrial Complex is designed to extract as much cash from the coffers as possible without regard for the value added to national defense. This is yet another example of two sides yelling past each other where the Left simply insists on cutting military spending and the Right glorifies the military and salutes increased spending as "patriotic". This is the rot of our politics today across all projects...
Why I love NixOS (birkey.co)
•
I love Nixos. Having a deterministic system is such a great way to know what your system is capable of. The only thing that bothers me is that when I rebuild my system after updating the lock file, if a package is broken the whole upgrade become impossible.
•
nixos is love. nixos is life. once you grok it, there's no going back. see you on the other side.
•
I'd love NixOS more if they had any decent documentation. Everything seems scattered around a dozen forums, a hundred old blog posts, and a thousand issues of "this work on my machine (3 releases ago)".
•
It doesn't help that there are two NixOS wikis. nixos.wiki and wiki.nixos.org. wiki.nixos.org claims that nixos.wiki is outdated and unofficial. But both appear to receive updates, and which one wins the SEO game is a coinflip whenever i google a nixos question.
•
A lot of us use NixOS/nix yet haven't read any documentation nor hand-written nix ourself. That's Claude Code's job.
•
ChatGPT is very good at pulling it together to give you working code. Not on the first try, but on the third try it usually works.
•
my entire system is configured using a flake i built with coding agent and skills to tell it how to configure things in nixos heh
•
My love for NixOS really became clear when I realized I never have to write Nix again by hand. A WIP NixOS config for working with agents: https://github.com/dangirsh/tsurf
•
Same. I have a full homelab and multiple macs, can’t say I’ve written a line of real Nix code by hand. If you’re itching to try Nix, now is the time.
•
Same. Can't imagine going back to the status quo where my system is the accumulation of terminal commands over time instead of a config file.
The problem I have with nix is that I just don't need another hobby. Keeping everything up to date in an ever changing environment like an os just looks like chore. I install my system and image it every week and keep maybe the initial and a monthly snapshot. Why would nix be better in my case? Maybe I am missing something essential but I also don't bork my system that often tbh.
•
For me, it's the difference between taking your medicine a bit at a time on your own schedule or taking it all at once as an unwelcome surprise. Sure, setting up file system mounts or adding udev entries is easier to do once in Ubuntu than in NixOS, but I only need to do it the one time with NixOS. Thereafter, the config serves as both documentation and backup. For a hobby self hoster like me shho occasionally shoots himself in the foot and has to rebuild a system, it is ideal. I don't know if it really saves me time, but I do know it saves my sanity. I am no nix whiz, but it's the only OS I run outside of containers. Anything I can't easily get with my nix config I shove into a container, run it as a quadlet, and call it good.
•
Imo it's the opposite. Since the system is defined in config files, an AI agent can look at live system state/errors vs. the config file and do all the work of figuring out the issue. Also, using higher level modules like home manager makes things more declarative and less fiddly since someone else is maintaining the lower level. Maybe nix is a downgrade for what you do. But I loved nix so much that I also migrated to nix on macOS (nix-darwin). No more homebrew.
•
nixos updates tend to be a lot less eventful than others distro, in fact the way it largely prevent system borking when updating, is spiritually freeing.
The idea is so good it’s as close to platonic as it gets. The user experience of writing your own nix expressions is so bad that it makes me angry every time I try. Not only that, but at some point the beginner help (!) meta became »use flakes, don’t do what the existing tutorials tell you, yes flakes are unstable beta and there are no tutorials but use it I beg you«. No, please, let me choose my own way to learn! I haven’t given it a shot in the LLM age yet though, and trying out NixOS in a VM is not only easy, it is practical – in the sense that when you’re happy, you can simply boot that same config/OS anywhere else by just installing that config. And I’ll never forget that one time where I completely borked my everything in the VM, did a kernel rollback with like 3 command line args and a reboot, and the OS was, well, rolled back. As I said, almost platonic. What I can recommend is using nix-the-package-manager. Whenever I need the newest version of something, `nix-env -i <whatever>` and it’s there and works. If it doesn’t, roll back. If I need a different version, that’s on nixpkgs as well, with the same negligible amount of friction.
•
>I haven’t given it a shot in the LLM age I haven't tried it in almost a year, but using Claude Code for setting up my nix config back then worked amazingly well. I've only dabbled in NixOS, and I'm very tempted to it for my workstation when I reinstall it in the next month. Given how much Claude Code + Opus have improved in the last year, I'd give it a fighting chance to make a nice Nix config. I'll probably start setting up a spare laptop to get the base configs dialed in before switching over to it.
•
LLMs are a real gamechanger for Nix, highly recommend giving it a go again.
doesn't it use up a lot of disk space compared to other distros because of the way everything is set up?
•
Yes, however the space is not „used up” in a classic sense. It’s a cache, so you can give up some of it and reclaim your space. Fresh after a full cleanup it won’t take much more than a regular distro.
•
actually once I garbage collect, nixos actually uses up less disk space for me than other distros
•
Yep disk space and learning curve are the two major downsides to Nix. The former has never been a problem for me in practice, just run garbage collection once a month. The latter was a big problem, but is now mitigated for most people by LLMs.
I don’t any experience with Nix - but how does it handle software which runs its own updating processes outside the package manager? Specifically thinking about software like Discord, Slack, Docker Desktop, Jetbrains Toolbox, etc. Is the Nix-ism to just reject using such software?
•
For a personal desktop environment, I just install them normally when there's no up to date nixified option. For some things I've vibe-coded a nix module on github that uses a scheduled github action to check for underlying app updates and then it generates a new hash and tags a release. I've done that for claude code and cursor, which is also an opportunity to let me manage their config files from my nix config.
So Discord, and quite a lot of software like this has actually two layers of updates. There's updates of the web page (which is basically writing a bunch of JS to the home directory) which NixOS does nothing to prevent, and then there's updates of the host program (i.e. Electron) which NixOS disables. Jetbrains Toolbox is in a sort of different category with tools like Rustup, since it's a package manager of its own. If you manage your IDEs with Toolbox, then your IDE versions are "outside Nix" and not managed by Nix. It's just packaged into its own pretend FHS environment and then doesn't know anything about it being on Nix. That said, updates of Toolbox itself will need to happen through your package manager. As a last comment, why run Docker Desktop on Linux at all? Like I understand on Windows and Mac - docker is inherently tied to Linux so the Windows/Mac apps abstract away the fact that it's running a VM and doing a bunch of port mapping and filesystem mounting under the hood so you can pretend it's not running on a VM, but on Linux I've always just installed docker straight onto the host.
•
There’s more to Docker Desktop than just “oh it’s just docker underneath” 1. Unified experience across Windows, Mac, Linux 2. The security posture is much stronger by default. Many people, who would probably be considered the “target audience” for Docker Desktop, don’t bother to make docker-ce rootless, or don’t use podman, so running it in a VM is better, though admittedly often annoying. 3. Not everybody is a CLI warrior. Docker Desktop gives a decent GUI, ways to monitor and control containers visually, and even deploy kubernetes with a single click.
•
This is a really helpful explanation - thank you! Regarding Docker Desktop on Linux - yeah definitely not strictly necessary. Sometimes it’s just convenient to have a UI instead of fumbling around trying to remember some cli incantation to check for dangling volumes or what-have-you. I think ideally I want to move to Podman anyways - but I’m using pop_os as my dev distro at the moment and am stuck on an older version which doesn’t have their native `podman compose` implementation yet
Although I’ve never committed to using nix system-wide, I do enjoy nix-based using https://devenv.sh/ for the very reasons described in the article. It’s much easier than local containers for development.
•
I've never really understood how version pinning is meant to work with devenv.sh or Nix more generally. If I whack a .tool-versions file in my repo, everyone who works on it can use install the exact same versions of the relevant tools using asdf. That's low tech and imperfect (and certainly not a replacement for all of Nix's features), but it works as far as it goes. None of the examples on the devenv.sh page demonstrate pinning of tools/packages to specific versions. As best I can tell, Nix enthusiasts think that this is an XY problem and that I shouldn't want to pin individual tools/packages to arbitrary versions. But the thing is that I am a rude barbarian who very much does want to do this, however philosophically misguided it might be.
What would the in between be?
•
Use it for a month or two and decide it's not for you. That is in between "use it for very short period of time" and "use it forever"
Introducing DoorDash Tasks (about.doordash.com)
•
Funny to see how creatively tech marketing teams are spinning their push for a permanent underclass in America. No employment contracts. No benefits. No protections. Unpredictable wages. But hey, it's great because in this new model people have "flexibility" and "freedom".
•
I wonder who can give tasks. And how do they combat potential abuse cases. Surely there is lot of tasks that can be exploited for more nefarious purposes. Or just simply exploiting those that would do the tasks.
•
Introducing DoorDash Deskilling.
•
So they’re training a model
•
There was a startup that did this in the mid 2010s named Magic, but was just via SMS. I used it a few times to get random things done, and it was really useful when it was cheap, then it became mega expensive.
•
Meta doesn’t even need to use this, they’re just going to be constantly recording all video and audio from those rayban glasses ;) Smart move, Zuck.
•
Definitely won't be abused by burglars, stalkers and spies.
•
Interesting - same concept as Amazon Mechanical Turk when you could crowdsource tasks
> Tasks and the new app are currently available in select places in the U.S., excluding California, New York City, Seattle and Colorado. Anyone know why that is? (Claude thinks it's because those places have gig worker protection laws such that "classifying Dashers as independent contractors for non-delivery work is most legally risky")
•
I have no idea but when reading the article my mind immediately went to businesses having dashers take photos of competing businesses as some type of weird crowdsourced corporate espionage.
•
Probably exactly that. Those places have minimum wage laws for gig workers.
Neither of these two things are something that DoorDash as a company can realistically do anything about.
•
DoorDash lobbies heavily against laws that would regulate labor, or classify its workers as “employees” and thus require they be covered by the minimal protections our country offers.
•
If only there was some other kind of employment model where people had regular shifts and they were paid consistently and transparently. Unfortunately I also do my office work by logging into an app at 6AM every day and bidding on a white collar job for a mystery amount of time and money
•
I am pretty sure that DoorDash employs quite a few of people for their tasks at hand.
•
Notably not the people who actually make the company money, though.
It's essentially mystery shopping. There's a pretty big disconnect between what a large corporate HQ thinks occurs at their stores and what actually occurs at their stores.
•
Its mystery shopping without any of those pesky minimum wage requirements
↙ time adjusted for second-chance
Reports of code's death are greatly exaggerated (stevekrouse.com)
•
> We're not confused with writing because there's nothing mystical about syntactically correct sentences in the same way there is about running code. Nobody is out there claiming that ChatGPT is putting the great novelists or journalists out of jobs. We all know that's nonsense If you compare great writing to programming then basically most of the industry vanishes and a few programming poets survive.
•
Yet again we can pull out Edsger W.Dijkstra's 1978 article, "On the foolishness of "natural language programming"" "In order to make machines significantly easier to use, it has been proposed (to try) to design machines that we could instruct in our native tongues. this would, admittedly, make the machines much more complicated, but, it was argued, by letting the machine carry a larger share of the burden, life would become easier for us. It sounds sensible provided you blame the obligation to use a formal symbolism as the source of your difficulties. But is the argument valid? I doubt."
•
It's only dead to those who are ignorant to what it takes to build and run real systems that don't tip over all the time (or leak data, embroil you in extortion, etc). That will piss some people off but it's worth considering if you don't want to perma-railroad yourself long-term. Many seem to be so blinded by the glitz, glamour, and dollar signs that they don't realize they're actively destroying their future prospects/reputation by getting all emo about a non-deterministic printer. Valuable? Yep. World changing? Absolutely. The domain of people who haven't the slightest clue what they're doing? Not unless you enjoy lighting money on fire.
•
> non-deterministic printer. I interpret non-deterministic here as “an LLM will not produce the same output on the same input.” This is a) not true and b) not actually a problem. a) LLMs are functions and appearances otherwise are due to how we use them b) lots of traditional technologies which have none of the problems of LLMs are non-deterministic. E.g., symbolic non-deterministic algorithms. Non-determinism isn’t the problem with LLMs. The problem is that there is no formal relationship between the input and output.
When I started my professional life in the 90s, we used Visual J++ (Java) and remember all this damn code it generated to do UIs... I remember being aghast at all the incomprehensible code and "do not modify" comments - and also at some of the devs who were like "isn't this great?". I remember bailing out asap to another company where we wrote Java Swing and was so happy we could write UIs directly and a lot less code to understand. I'm feeling the same vibe these days with the "isn't it great?". Not really!
•
Oh the memories, but at least that generated code was deterministic...
•
You just brought me back to my first internship where as interns we were asked to hand-manipulate a 30k lines auto-generated SOAP API definition because we lost the license to the software that generated it
In a chat bot coding world, how do we ever progress to new technologies? The AI has been trained on numerous people's previous work. If there is no prior art, for say a new language or framework, the AI models will struggle. How will the vast amounts of new training data they require ever be generated if there is not a critical mass of developers?
•
Maybe you’re right about modern LLMs. But you seem to be making an unstated assumption: “there is something special about humans that allow them to create new things and computers don’t have this thing.” Maybe you can’t teach current LLM backed systems new tricks. But do we have reason to believe that no AI system can synthesize novel technologies. What reason do you have to believe humans are special in this regard?
•
That's irrelevant. The claim being made is not "no computer will ever be able to adapt to and assist us with new technologies as they come out." The claim being made is "modern LLMs cannot adapt to and assist us with new technologies until there is a large corpus of training data for those technologies." Today , there exists no AI or similar system that can do what is being described. There is also no credible way forward from what we have to such a system. Until and unless that changes, either humans are special in this way, or it doesn't matter whether humans are special in this way, depending on how you prefer to look at it.
•
After thousands of years of research we still don’t fully understand how humans do it, so what reason (besides a sort of naked techno-optimism) is there to believe we will ever be able to replicate the behavior in machines?
•
In a chat bot coding world, how do we ever progress to new technologies? Funny, I'd say the same thing about traditional programming. Someone from K&R's group at Bell Labs, straight out of 1972, would have no problem recognizing my day-to-day workflow. I fire up a text editor, edit some C code, compile it, and run it. Lather, rinse, repeat, all by hand. That's not OK. That's not the way this industry was ever supposed to evolve, doing the same old things the same old way for 50+ years. It's time for a real paradigm shift, and that's what we're seeing now. All of the code that will ever need to be written already has been. It just needs to be refactored, reorganized, and repurposed, and that's a robot's job if there ever was one.
•
You're probably using an IDE that checks your syntax as you type, highlighting keywords and surfacing compiler warnings and errors in real time. Autocomplete fills out structs for you. You can hover to get the definition of a type or a function prototype, or you can click and dig in to the implementation. You have multiple files open, multiple projects, even. Not to mention you're probably also using source control, committing code and switching between branches. You have unit tests and CI. Let's not pretend the C developer experience is what it was 30 years ago, let alone 50.
•
While i dont disagree with the larger point here i do disagree that all the code we ever need has been written. There are still soooooo many new things to uncover in that domain.
•
Like what?
•
This would also mean that we should design new programming languages out of sight of LLMs in case we need to hide code from them.
People are doing this now. It's basically what skills.sh and its ilk are for -- to teach AIs how to do new things. For example, my company makes a new framework, and we have a skill we can point an agent at. Using that skill, it can one-shot fairly complicated code using our framework. The skill itself is pretty much just the documentation and some code examples.
•
The question is, who made the new framework? Was it vibe coded by someone who does not understand its code?
•
No, it was created by our team of engineers over the last three years based on years of previous PhD research.
•
A framework is different than a paradigm shift or new language.
•
Yes and no. How does a human learn a new language? They use their previous experience and the documentation to learn it. Oftentimes they way someone learns a new language is they take something in an old language and rewrite it. LLMs are really good at doing that. Arguably better than humans at RTFM and then applying what's there.
Most art forms do not have a wildly changing landscape of materials and mediums. In software we are seeing things slow down in terms of tooling changes because the value provided by computers is becoming more clear and less reliant on specific technologies. I figure that all this AI coding might free us from NIH syndrome and reinventing relational databases for the 10th time, etc.
•
LLMs are very much NIH machines
•
The bar to create the new X framework has just been lowered so I expect the opposite, even more churn.
That’s factually untrue. I’m using models to work on frameworks with nearly zero preexisting examples to train on, doing things no one’s ever done with them, and I know this because I ecosystem around these young frameworks. Models can RTFM (and code) and do novel things, demonstrably so.
•
Yeah. I work with bleeding edge zig. If you just ask Claude to write you a working tcp server with the new Io api, it doesn’t have any idea what it’s doing and the code doesn’t compile. But if you give it some minimal code examples, point it to the recent blog posts about it, and paste in relevant points from std it does incredibly well and produce code that it has not been trained on.
Yeah, I don't really accept the argument that AI makes mistakes and therefore cannot be trusted to write production code (in general, at least - obviously depends on the types of mistakes, which code, etc.). The reality is we have built complex organizational structures around the fact that humans also make mistakes, and there's no real reason you can't use the same structures for AI. You have someone write the code, then someone does code review, then someone QAs it. Even after it goes out to production, you have a customer support team and a process for them to file bug tickets. You have customer success managers to smooth over the relationships with things go wrong. In really bad cases, you've got the CEO getting on a plane to go take the important customer out for drinks. I've worked at startups that made a conscious decision to choose speed of development over quality. Whether or not it was the right decision is arguable, but the reality is they did so knowing that meant customers would encounter bugs. A couple of those startups are valuable at multiple billions of dollars now. Bugs just aren't the end of the world (again, most cases - I worked on B2B SaaS, not medical devices or what have you).
•
> humans also make mistakes This is broadly true, but not comparable when you get into any detail. The mistakes current frontier models make are more frequent, more confident, less predictable, and much less consistent than mistakes from any human I'd work with. IME, all of the QA measures you mention are more difficult and less reliable than understanding things properly and writing correct code from the beginning. For critical production systems, mediocre code has significant negative value to me compared to a fresh start. There are plenty of net-positive uses for AI. Throwaway prototyping, certain boilerplate migration tasks, or anything that you can easily add automated deterministic checks for that fully covers all of the behavior you care about. Most production systems are complicated enough that those QA techniques are insufficient to determine the code has the properties you need.
most human bugs are caused by failures in reasoning though, not by just making something up to leap to the conclusion considered most probable, so not sure if the comparison makes sense.
•
> most human bugs are caused by failures in reasoning though Citation needed.
•
sorry, that is just taken from my experience, and perhaps I am considering reasoning to be a broader category than others might. To be lenient I will separate out bugs caused by insufficient knowledge as not being failures in reasoning, do you have forms of bugs that you think are more common and are not arguably failures in reasoning that should be considered?
For future greenfield projects, I can see a world where the only jobs are spec-writer and test-writer, with maybe one grumpy expert coder (aka code janitor) who occasionally has to go into the code to figure out super gnarly issues.
•
A good spec-writer, as the article notes, is writing code.
•
This is already happening, many days I am that grumpy "code janitor" yelling at the damn kids to improve their slop after shit blows up in prod. I can tell you It's not "fun", but hopefully we'll converge on a scalable review system eventually that doesn't rely on a few "olds" to clean up. GenAI systems produce a lot of "mostly ok" code that has subtle issues you on catch with some experience. Maybe I should just retire a few years early and go back to fixing cars...
•
Yeah I imagine it has to be utterly thankless being the code janitor right now when all the hype around AI is peaking. You're basically just the grumpy troll slowing things down. And God forbid you introduce a regression bug trying to clean up some AI slop code. Maybe in the future us olds will get more credit when apps fall over and the higher ups realize they actually need a high-powered cleaner/fixer, like the Wolf in Pulp Fiction.
•
I’ve got a “I haven’t written a line of code in one year” buddy whose startup is gaining traction and contracts. He’s rewritten the whole stack twice already after hitting performance issues and is now hiring cheap juniors to clean up the things he generates. It is all relatively well defined CRUD that he’s just slapped a bunch of JS libs on top of that works well enough to sell, but I’m curious to see the long term effects of these decisions. Meanwhile I’m moving at about half the speed with a more hands on approach (still using the bots obviously) but my code quality and output are miles ahead of where I was last year without sacrificing maintain ability and performance for dev speed
My problem is that while I know “code” isn’t going away, everyone seems to believe it is, and that’s influencing how we work. I have not really found anything that shakes these people down to their core. Any argument or example is handwaved away by claims that better use of agents or advanced models will solve these “temporary” setbacks. How do you crack them? Especially upper management.
•
To an extent, these people have found their religion, and rational discussion does not come into play. As with previous tech Holy Wars over operating systems, editors, and programming languages, their self-image is tied to the technology. Where the tech argument doesn't apply to upper management, business practices, the need to "not be left behind" and leap at anything that promises reducing headcount without reducing revenue, money talks. As long as it's possible to slop something together, charge for it, and profit, slop will win.
As a former PM, I will say that if you want to stop something from happening at your company, the best route is to come off very positive about it initially. This is critical because it gives you credibility. After my first few years of PMing, I developed a reflex that any time I heard a deeply stupid proposal, I would enthusiastically ask if I could take the lead on scoping it out. I would do the initial research/planning/etc. mostly honestly and fairly. I'd find the positives, build a real roadmap and lead meetings where I'd work to get people onboard. Then I'd find the fatal flaw. "Even though I'm very excited about this, as you know, dear leadership, I have to be realistic that in order to do this, we'd need many more resources than the initial plan because of these devastating unexpected things I have discovered! Drat!" I would then propose options. Usually three, which are: Continue with the full scope but expand the resources (knowing full well that the additional resources required cannot be spared), drastically cut scope and proceed, or shelve it until some specific thing changes. You want to give the specific thing because that makes them feel like there's a good, concrete reason to wait and you're not just punting for vague, hand-wavy reasons. Then the thing that we were waiting on happens, and I forget to mention it. Leadership's excited about something else by that point anyway, so we never revisit dumb project again. Some specific thoughts for you: 1. Treat their arguments seriously. If they're handwaving your arguments away, don't respond by handwaving their arguments away, even if you think they're dumb. Even if they don't fully grasp what they're talking about, you can at least concede that agents and models will improve and that will help with some issues in the future. 2. Having conceded that, they're now more likely to listen to you when you tell them that while it's definitely important to think about a future where agents are better, you've got to deal with the codebase right now. 3. Put the problems in terms they'll understand. They see the agent that wrote this feature really quickly, which is good. You need to pull up the tickets that the senior developers on the team had to spend time on to fix the code that the agent wrote. Give the tradeoff - what new features were those developers not working on because they were spending time here? 4. This all works better if you can position yourself as the AI expert. I'd try to pitch a project of creating internal evals for the stuff that matters in your org to try with new models when they come out. If you've volunteered to take something like that on and can give them the honest take that GPT-5.5 is good at X but terrible at Y, they're probably going to listen to that much more than if they feel like you're reflexively against AI.
•
It's even better when you guide them into finding the fatal flaw for themselves.
•
Hahaha yes this is absolutely true but often times so much more work.
MAUI Is Coming to Linux (avaloniaui.net)
•
Just a reminder that this MAUI has nothing to do with the pre-existing cross platform UI framework MauiKit from MAUI Project. https://mauikit.org/
•
From a quick look, I can't find a reason. why? Even MS doesn't fully believe in Maui, as it seems they reblessed WPF. For Avalonia to do the work of MS seems weird, their own free regular WPF-like Avalonia UI toolkit is already the standard for cross desktop development. I was looking for the line: Microsoft sponsored us. Even then I would not understand why they would spend effort on a doomed project. I know Avalonia being a small company has a big task ahead of porting Avalonia UI to Wayland, which makes porting MS semi-abandonware all the more confusing. But since these people aren't idiots, I gladly assume I am missing something.
•
The rewrite from Xamarin.Forms into MAUI, has given a bad taste to many in the community, and kudos to Avalonia to make it happen on GNU/Linux. By the way on macOS MAUI uses Catalyst as backend, not native macOS APIs. Also it is kind of interesting that Miguel de Icaza, nowadays completely switched into Swift ecosystem, and is the responsible for making game development on iPad with Godot a reality. Or porting old .NET ideas of his into Swift.
•
I like the possibilities this opens up but I'm struggling to understand how wasm is involved. I had the impression it doesn't have a user interface, but it's called by javascript instead.
What is unclear to me, is how does it work with Avalonia pricing wise? If I am having commercial application for Windows, Android, MacOS, iOS (Microsoft MAUI range) then according to [1] I would need to dish out 125000 EUR per application. But it was never clear to me what are the conditions which actually triggers the difference between free and paid plan. [1] https://avaloniaui.net/xpf/pricing
•
Let me rephrase what sibling said: the paid offering is for you when you have gotten an existing traditional windows-only wpf application and you want to have that appplication cross-platform as-is , foregoing any effort to port it to AvaloniaUI. You won't need the paid offering if you build your stuff in AvaloniaUI directly.
•
Avalonia is free and open-source. Avalonia MAUI currently appears to be MIT as well [0]. The pricing you’ve linked to is pricing for their paid offering, which wraps Avalonia and a WPF-style API for easy migration of legacy apps. [0] https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/main/LICENSE
I can understand the confusion, Microsoft also has a framework called MAUI.
•
The MAUI they are talking about is the Microsoft framework you are referencing. MAUI is Open Source but Microsoft does not provide a Linux back-end. This is a non-Microsoft effort to bring Linux support to MAUI.
•
The Microsoft MAUI framework is the one being brought to Linux by Avalonia, yes.
I wish they support Linux wholeheartedly, a lot of toolkits and GUI frameworks do it by half-assing things, mostly because Wayland is difficult to understand. In Wayland you have multiple ways to render windows, not just the XDG top level window. It works via surfaces, and here is a list I've discovered so far: - XDG Top Level Window - Child Window - Popup Surface - Layer surface (like task-bars, shell overlays) - Subsurface (region in another surface) - IME Panel Surface (surface that follows text cursor) There probably is others too. It is diffifcult to find high-level toolkits that support all of the above.
•
Not to mention that there's no clear documentation for this anywhere. A while ago I was attempting to debug some Wayland-specific issues with a graphics library, it turns out the issue was that the little documentation there was, was wrong about what is and isn't nullable.
You are not your job (jry.io)
Nobody needs private school, give me a fucking break.
•
It's an example, you give me a fucking break.
There’s an old aphorism: “Do what you love, and you’ll never work a day in your life.” I worked in tech, because I love tech . No other reason, really. I accepted a job, making maybe half of what I could make, elsewhere, because of the personal satisfaction I got from it, and the relationships I made, there. When I retired, I have continued to develop software, and am currently “leaning into” AI-assisted development. During that time, I’ve also had plenty of time to be human.
•
That's a very privileged thing to say about a career where the tools to replace developers did not exist
I want to thank everyone who hates work, is mentally checked out of their jobs and quiet quitting etc. It makes it much easier for me to distinguish myself as a hard worker who cares about the business being successful. It also helps me keep my job during layoffs because I can assure you the managers have noticed. When you are old and have lots of formative experiences that are not work-based, we can shake hands and mutually appreciate each other's motives and respective outcomes.
•
I mostly agree with the parent post. There certainly are roles where the entire scope of the job is to convert Jira tickets to code and nothing else and nobody will blame you for being a checked out 9-5er in such places but that isn't the audience of HN. Most here are software engineers who get fairly broad latitude to exercise judgment and expertise/education in furtherance of business goals and that's they get the FAANG-sized paycheck and RSUs/stock grants for. And you better believe colleagues in those roles notice who is just doing the minimum and who is helping to achieve goals.
The Future of Version Control (bramcohen.com)
•
Why must everyone preprocess their blog posts with ChatGPT? It is such a disservice to ones ideas.
•
I think there are still strong advantages to the centralized locking style of collaboration. The challenge is that it seems to work best in a setting where everyone is in the same physical location while they are working. You can break a lock in 30 seconds with your voice. Locking across time zones and date lines is a nonstarter by comparison.
•
This is cool and i keep thinking about CRDTs as a baseline for version control, but CRDTs has some major issues, mainly the fact that most of them are strict and "magic" in the way they actually converge(like the joke: CRDTs always converge, but to what). i didn't read if he's using some special CRDT that might solve for that, but i think that for agentic work especially this is very interesting
•
Nobody should have these types of problems in the age of AI agents. This kind of clean up and grunt work is perfect for AI agents. We don’t need new abstractions.
•
Version control systems are more important than ever with AI.
•
Not this again
•
> [CRDT] This means merges don’t need to find a common ancestor or traverse the DAG. Two states go in, one state comes out, and it’s always correct. Funny, there was just a post a couple of days ago how this is false. https://news.ycombinator.com/item?id=47359712
> [CRDT] This means merges don’t need to find a common ancestor or traverse the DAG. Two states go in, one state comes out, and it’s always correct. Well, isn't that what the CRDT does in its own data structure ? Also keep in mind that syntactic correctness doesn't mean functional correctness.
•
Yes. There are many ways to instantiate a CRDT, and a trivial one would be "last write wins". LWW is obviously not what you'd want for source version control. It is "correct" per its own definition, but it is not useful. Anyone saying "CRDTs solve this" without elaborating on the specifics of their CRDT is not saying very much at all.
The thing about how merges are presented seems orthogonal to how to represent history. I also hate the default in git, but that is why I just use p4merge as a merge tool and get a proper 4-pane merge tool (left, right, common base, merged result) which shows everything needed to figure out why there is a conflict and how to resolve it. I don't understand why you need to switch out the VCS to fix that issue.
•
Even if you don’t use p4merge, you can set Git’s merge.conflictStyle config to "diff3" or "zdiff3" ( https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle ). If you do that, Git’s conflict markers show the base version as well: <<<<<<< left ||||||| base def calculate(x): a = x * 2 b = a + 1 return b ======= def calculate(x): a = x * 2 logger.debug(f"a={a}") b = a + 1 return b >>>>>>> right With this configuration, a developer reading the raw conflict markers could infer the same information provided by Manyana’s conflict markers: that the right side added the logging line.
•
That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some representation of the DAG. Something like base, that is "common base", looks far more apt to my mind. In the same vein, endogenous/exogenous would be far more precise, or at least aligned with the concern at stake. Maybe "local/alien" might be a less pompous vocabulary to convey the same idea.
•
I'm on my phone right now so I'm not going to dig too hard for this, but you can also configure a "merge tool" (or something like that) so you can use Meld or Kompare to make the process easier. This has helped me in a pinch to work out some confusing merge conflicts.
•
I started using Meld years ago and continue to find people who've never heard of it. It's a pretty good tool.
My issue with git is handling non-text files, which is a common issue with game development. git-lfs is okay but it has some tricky quirks, and you end up with lots of bloat, and you can't merge. I don't really have an answer to how to improve it, but it would be nice if there was some innovation in that area too.
•
Totally agree. After trying to flesh out Unreal's git plugin, it really shows how far from ideal git really is. Partial checkouts are awkward at best, LFS locks are somehow still buggy and the CLI doesn't support batched updates. Checking the status of a remote branch vs your local (to prevent conflicts) is at best a naive polling. Better rebase would be a nice to have but there's still so much left to improve for trunk based dev.
•
What strategies would you like to use to diff the binaries? Or else how are you going to avoid bloat? Is it actually okay to try to merge changes to binaries? If two people modify, say, different regions of an image file (even in PNG or another lossless compression format), the sum of the visual changes isn't necessarily equal to the sum of the byte-level changes.
> You can commit with conflicts unresolved. True but it is not valid syntax. Like, you mean with the conflict lines?
•
The way I'm reading it (and reading in between the lines) there wouldn't be conflict lines in the file. You'd still have the conflict to resolve eventually, but not tracked by representing it in the file with conflict markup in it. I could be way off base but that is what it seems the claim is to me. The resulting merge before you've resolved may not compile or work of course. I think in the example in the article the inserted line from the right is floating in space because the left deleted the function it was in. So you probably will need to resolve that conflict immediately if you want the program to compile. But what's happening is the merge has already happened, and the algorithm knows it merged something where changes were too close to each other and someone needs to review it. The conflict view is just a view of what changes were merged, rather than being conflict markup in the file itself.
Yeah this seems silly. You can do the same thing in git (add and commit with the conflict still there)! Why you would want to is a real mystery.
•
It allows review of the way the merge conflict has been resolved (assuming those changes a tracked and presented in a useful way). This can be quite helpful when backporting select fixes to older branches.
I hate: Programming Wayland applications (p4m.dev)
I might be mistaken, but isn't this what libraries like winit exist for? It might not be just for wayland, but it seems like it supports everything you mentioned other than drag and drop.
•
Generally yes (or GLFW, or SDL), but the Wayland project shouldn't delegate the job to burned out hobbyists (who will think twice before wasting their time with bad APIs). This client library should really be a mandatory part of each Wayland install as a system library, not part of the application. And most importantly, the Wayland project needs to start eating their own dogfood, or things will never improve.
Callbacks are bad?
•
Yes. See also this article[0] for what then happens to the rest of your codebase. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function
Which is kind of understandable as Wayland tries to be more secure: and thus in Wayland not all keyboard events are propagated to all applications (that's what X11 does). I think it's a good idea to put security first in this iteration of FLOSS desktop technology.
•
Phoenix[0] has some good ideas about how X11 could be made more secure without breaking backwards compatibility. I don't understand what was so fundamentally broken about X11 as a protocol that it required a replacement protocol. We can argue about limitations of X.org's implementation of the X server, but, as demonstrated by Phoenix, X.org doesn't have to be the only X server implementation. [0]: https://git.dec05eba.com/phoenix
•
I have no idea, but my impression was that basically nobody wanted to put in work on X11 anymore.
No, nothing deserves this constant whining and crying day in and day out. Especially coming from people who don't put in the work to build something else. It's really bizarre how the opensource community degraded into this space of constant aggresive, insulting screeching over every single project thats actually moving something in the Linux world. Coming from people who don't put any code behind it or do anything but attack any change since 1990s. To hell with that, Linux developers deserve better than this constant barrage of hate.
•
Tbh, it's quite delusional to think that a better alternative solution would win that's not backed by Redhat and GNOME. In a purely competitive environment, a design like Wayland could never have "won" as an X11 replacement, it was pushed long enough until it was "too big to fail".
There are ~three groups in the systemd debate. People who grew up on sysvinit based service management and can't handle change (the partially straw man group you are complaining about). People who only know about sysvinit based service management and systemd and formed their opinions of systemd based on "sysvinit == terrible confusing shell scripts; systemd == config files" (you - as a first impression). And people who actually know the advantages, disadvantages, and functional details of sysvinit based service management, systemd, and the plethora of other attempts/approaches at solving these issues and can support their arguments in favour of or against systemd with actually reasoned arguments. The first group is easy to ignore, and a minority. The third group produces the biggest chunk of well informed content on systemd. And the second group seems to think that anyone in the third group who is in favour of systemd, must be one of them, and anyone who is against systemd, must be in the first group (note also: the false dichotomy). Rather than straw manning your opponents in this discussion while pretending this is a discussion of the pros and cons of "declarative service management", could you instead contribute something useful? Lacking that, maybe just stop trying to contribute? By saying stuff like this, you aren't going to convert sysvinit users to anything and you aren't going to convince anyone who has genuine criticism of systemd of anything.
•
You're right I do fall into category 1
That is a strawman. That is not the aspect of systemd people object to.
•
That's fair. I have not interacted with it beyond using journalctl to debug various services and I found it easy to work with
Yawn, X11 (and similar "unsecure" desktop environments) existed for half a century and the sky hasn't fallen. I'm tired of that "will somebody think of the children/grandparents" scare mongering.
•
It hasn't, but Windows has had its fair share of keyloggers, RATs, and so on, and I think we can all agree that anti-virus software is an inherently flawed concept. The only thing keeping those away from Linux was its market share. With npm malware on the rise, this is no longer enough of a protection.
I was going to point out that wayland is a protocol & surely there must be other ways to do this. But your point about mesa expecting wayland-client is a very tight binding here. Anyone know of exceptions? People who get mesa working anyhow, some way? It also doesn't preclude people from making nicer experiences on top of libwayland. Again I'd be curious to see what material is out there. It feels like a library that materializes the current state of things into a local view would go a long way to dispel the rage of people such as the author here, who seem to detest callbacks with firey rage. The idea of the wayland registry seem unifying & grand to me. Ok yes it's async & doesn't hide it? Lot of ink spilled to be upset about that, and doesn't feel like an immutable fact that must govern life, if that for some reason makes you as mad as this dude.
•
> But your point about mesa expecting wayland-client is a very tight binding here. You don't have to use Mesa's wayland-egl to make EGL work with Wayland, you can easily pass dmabufs by yourself - though this will theoretically be less portable as dmabufs are Linux specific (but practically they're also implemented by various BSDs).
There is nothing "niche" about plugging in a modern (e.g. made within last 5 years) laptop into an external display. These kind of posts just show how disconnected from reality some of y'all are from what most Linux desktop users nowadays actually need from the desktop platform.
•
I always plug my laptop into one or two external displays. Even without configuring distinct DPIs per monitor that was not a problem for me, because on the small screen of the laptop I kept only some less important application, like the e-mail program, while working on the bigger external displays, so I had no reason to move windows between the small screen of the laptop and the bigger external displays. But like I said, setting a different DPI value for each monitor has been added to X11 many years ago, I do not remember how many. I do not see why one would want to move windows between the external displays and the laptop, when you have connected external displays, so I consider this a niche use case, i.e. moving windows between small screens and big screens. I agree with you that having simultaneously big screens and small screens is not niche, so I was not referring to this. Without a per-screen DPI value you cannot control the ratio between the sizes of a window when is moved between the big screen and the small screen, but even when you control the ratio, moving windows between screens of different sizes does not work well because you must choose some compromise, e.g. if you keep the same physical size some windows from the big screen will not fit on the small screen and if you make the windows occupy the same fraction of the screen size they will change their sizes during moving and they will be more difficult to use on the small screen. But like I have said, this no longer matters as the problem has been solved even for this niche use case. I do not even remember if this problem still existed by the time when Wayland became usable.
How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
•
> Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off. Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things. Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.
Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys. For example, I found this with ~2 minutes of Googling: https://wayland.app/protocols/hyprland-global-shortcuts-v1
•
> Not impossible, it just needs to be implemented at a different layer. Do you mean the Window Manager layer? That sounds like a different way of saying "impossible". In X11 I can create an automation tool that works regardless of the underlying WM, or even if there isn't an underlying WM. Can't do that with Wayland.
xdg-shell is an optional extension for a compositor and yet you can reliably deploy things that depend on it. You're barking at the wrong tree.
•
OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?
•
It's not a core protocol's concern and the fact that it's being successfully implemented proves that there are no fundamental limitations there. I'm not happy with how the collaboration and planning between various parties involved went over years and I do believe that a lot of these adoption pains are fully self-inflicted, but that has absolutely nothing to do with Wayland's technical design.
Bored of eating your own dogfood? Try smelling your own farts (shkspr.mobi)
This describes quite well the huge advantage small companies have vs big companies. (Motivated) people at small companies "care", and what I mean with that is they are responsible and can see a large enough portion of the customer experience that - if something is broken - they'll see the pain and try to address it. At a big company no one cares. They of course care about their job, but their job is such a small fraction of the overall customer experience, that seeing their work having an impact on their customer is exceptionally difficult. That's why large companies need to encode customer feedback into a system to imitate feedback cycles. Mostly in metrics. That's a very lossy way to capture signal, and leaves a lot to be desired, but so far it doesnt seem like anyone has come up with a better system.
•
> That's why large companies need to encode customer feedback into a system to imitate feedback cycles. Mostly in metrics. That's a very lossy way to capture signal, and leaves a lot to be desired, but so far it doesnt seem like anyone has come up with a better system. The other thing you can do is having senior leadership occasionally try the product themselves and talk directly to customers (especially ones that have problems). Often, problems remain because of bureaucratic hurdles, or disputes between different fiefdoms: there's a feature that needs teams X and Y to improve, but it would only help the internal metrics for team X, so team Y doesn't give a shit and drags their feet. Leaders who are sufficiently high in the hierarchy can cut through these sorts of problems if they know and care.
In my last role (engineering side) the VP of Product objected to me using the phrase "eating your own dogfood" because it was "gross" and she always interjected and replaced it with "drink your own champagne". I countered (privately) that was a feature; it's supposed to be a little unappetizing because you're early, building empathy and getting a different perspective (to a dog, dog food is delicious!). I think the difference in perspective succinctly illustrates the schism between trying to understand the customer experience asap, and the data-driven, kpi crowd where - conveniently - you can't discover these issues until it's too late.
•
It may amuse, or disturb, to report that a previous boss had an unfortunate mis-translation of the idiom as "eating our own dogshit".
Interesting. I prefer "champagne" as it clarifies the goal: to make something curated, crafted, and desired. I've never interpreted the dogfood v. champagne difference as anti-empathy somehow.
•
People will drink poor quality champagne after they've had one or two good glasses, so the analogy may be appropriate to modern software development.
But my own farts smell good
•
Yes. Talking about it is taboo, but it is quite a common phenomenon when people like the smell of their own farts and bodily odors.
The irony isn't lost on me, either. Googling does result with a Gemini/AI response at the top.
•
that's why you set &udm=14 in the search URL config...
A case against currying (emi-h.com)
I couldn't agree more. Having spent a lot of time with a language with currying like this recently, it seems very obviously a misfeature. 1. Looking at a function call, you can't tell if it's returning data, or a function from some unknown number of arguments to data, without carefully examining both its declaration and its call site 2. Writing a function call, you can accidentally get a function rather than data if you leave off an argument; coupled with pervasive type inference, this can lead to some really tiresome compiler errors 3. Functions which return functions look just like functions which take more arguments and return data (card-carrying functional programmers might argue these are really the same thing, but semantically, they aren't at all - in what sense is make_string_comparator_for_locale "really" a function which takes a locale and a string and returns a function from string to ordering?) 3a. Because of point 3, our codebase has a trivial wrapper to put round functions when your function actually returns a function (so make_string_comparator_for_locale has type like Locale -> Function<string -> string -> order>), so now if you actually want to return a function, there's boilerplate at the return and call sites that wouldn't be there in a less 'concise' language! I think programming languages have a tendency to pick up cute features that give you a little dopamine kick when you use them, but that aren't actually good for the health of a substantial codebase. I think academic and hobby languages, and so functional languages, are particularly prone to this. I think implicit currying is one of these features.
•
> I think programming languages have a tendency to pick up cute features that give you a little dopamine kick when you use them, but that aren't actually good for the health of a substantial codebase. That's not the case with Haskell. Haskell has a tendency to pick up features that have deep theoretical reasoning and "mathematical beauty". Of course, that doesn't always correlate with codebase health very well either, and there's a segment of the community that is very vocal about dropping features because of that. Anyway, the case here is that a superficial kind of mathematical beauty seems to conflict with a deeper case of it.
That's a very good point, I never thought really about how this relates to the execution model & graph reduction and such. Do you have an example of a function where this can make a difference? I might add something to the article about it. It's also a question of whether this is exclusive to a curried definition or if such an optimization may also apply to partial application with a special operator like in the article. I think it could, but the compiler might need to do some extra work?
•
An example where this is useful is to help inline otherwise recursive functions, by writing the function to take some useful parameters first, then return a recursive function which takes the remaining parameters. This allows the function to be partially in-lined, resulting in better performance due to the specialization on the first parameters. For example, foldr: foldr f z = go where go [] = z go (x : xs) = f x (go xs) when called with (+) and 0 can be inlined to go xs = case xs of [] -> 0 (x : xs) = x + go xs which doesn't have to create a closure to pass around the function and zero value, and can subsequently inline (+), etc.
I think we need to see a few non-contrived examples, because i think in every case where you might take advantage of currying like this, you actually want to make it explicit, as you say. The flip side of your example is that people see a function signature like getClosest, and think it's fine to call it many times with a set and a point, and now you're building a fresh quadtree on each call. Making the staging explicit steers them away from this.
•
> and now you're building a fresh quadtree on each call [...] Making the staging explicit steers them away from this. Irrespective of currying, this is a really interesting point - that the structure of an API should reflect its runtime resource requirements.
I agree with this article. Tuples nicely unified multiple return values and multiple parameters. FWIW Scala and Virgil both support the _ syntax for the placeholder in a partial application. def add(x: int, y: int) -> int { return x + y; } def add3 = add(_, 3); Or more simply, reusing some built-in functions: def add3 = int.+(_, 3);
•
As noted in the article: > This feature does have some limitations, for instance when we have multiple nested function calls, but in those cases an explicit lambda expression is always still possible. I've also complained about that a while ago https://news.ycombinator.com/item?id=35707689 --- The solution is to delimit the level of expression the underscore (or dollar sign suggested in the article) belongs to. In Kotlin they use braces and `it`. { add(it, 3) } // Kotiln add(_, 3) // Scala Then modifying the "hole in the expression" is easy. Suppose we want to subtract the first argument by 2 before passing that to `add`: { add(subtract(it, 2), 3) } // Kotlin // add(subtract(_, 2), 3) // no, this means adding 3 to the function `add(subtract(_, 2)` x => { add(subtract(x, 2), 3) } // Scala
•
I think I like the explicit lambda better; I prefer to be judicious with syntactic sugar and special variable names. fun x => add(subtract(x, 2), 3) // Virgil
•
Coming from Scala to Kotlin, this is what I thought as well. Seeing `it` felt very wrong, then I got used to it.
Prior to this article, I didn't think of currying as being something a person could be "for" or "against." It just is. The fact that a function of multiple inputs can be equivalently thought of as a function of a tuple can be equivalently thought of as a composite of single-input functions that return functions is about cognition, and understanding structure, not code syntax.
•
I'm a programmer, not a computer scientist. The equivalence is a computer science thing. They are logically equivalent in theoretical computer science. Fine. They are not equally easy for me to use when I'm writing a program. So from a software engineering perspective, they are very much not the same.
Similar to how lambda calculus "just is" (and it's very elegant and useful for math proofs), but nobody writes non-trivial programs in it...
•
Make that almost nobody. I wrote a non-trivial lambda program [1] which enumerates proofs in the Calculus of Constructions to demonstrate [2] that BBλ(1850) > Loader's Number. [1] https://github.com/tromp/AIT/blob/master/fast_growing_and_conjectures/loader.lam [2] https://codegolf.stackexchange.com/questions/176966/golf-a-number-bigger-than-loaders-number/274634#274634
The functional programming take is that “the result of foobinade-ing an and b” IS “foobinade applied to two of its arguments”. The application is not some syntactic pun or homonym that can refer to two different meanings—those are the same meaning.
•
Let us postulate two functions. One is named foobinade, and it takes three arguments. The other is named foobinadd, and it only takes two arguments. (Yes, I know, shoot anybody who actually names things that way.) When someone writes f = foobinade a b g = foobinadd c d there is no confusion to the compiler. The problem is the reader . Unless you have the signatures of foobinade and foobinadd memorized, you have no way to tell that f is a curried function and g is an actual result. Whereas with explicit syntax, the parentheses say what the author thinks they're doing, and the compiler will yell at them if they get it wrong.
•
> Unless you have the signatures of foobinade and foobinadd memorized, you have no way to tell that f is a curried function and g is an actual result. Yes, but the exact FP idea here is that this distinction is meaningless; that curried functions are "actual results". Or rather, you never have a result that isn't a function; `0` and `lambda: 0` (in Python syntax) are the same thing. It does, of course, turn out that for many people this isn't a natural way of thinking about things.
•
Fine, it's a regular type. It's still not the type I think it is . If it's an Int -> Int when I think it's an Int, that's still a problem, no matter how much Int -> Int is an "actual result".
Please see my other comment below, and maybe re-read the article. I'm not asking what the difference is between curried and non-curried. The article draws a three way distinction, while I'm asking why two of them should be considered distinct, and not the pair you're referring to.
•
Apologies, I was focused on the usual pairing in this space and not the more subtle one you're talking about. As others have pointed out, there isn't really semantic a difference between the two. Both approaches to function parameters produce the same effect. The differences are purely in "implementation," either theoretically or in terms of systems-building. From a theoretical perspective, a tuple expresses the idea of "many things" and a multi-argument parameter list expresses the idea of both "many things" and "function arguments." Thus, from a cleanliness perspective for your definitions, you may want to separate the two, i.e., require function have exactly one argument and then pass a tuple when multiple arguments are required. This theoretical cleanliness does result in concrete gains: writing down a formalism for single-argument functions is decidedly cleaner (in my opinion) than multi-argument functions and implementing a basic interpreter off of this formalism is, subsequently, easier. From a systems perspective, there is a clear downside in this space. If tuples exist on the heap (as they do for most functional languages), you induce a heap allocation when you want to pass multiple arguments! This pitfall is evident with the semi-common beginner's mistake with OCaml algebraic datatype definitions where the programmer inadvertently wraps the constructor type with parentheses, thereby specifying a constructor of one-argument that is a tuple instead of a multi-argument constructor (see https://stackoverflow.com/questions/67079629/is-a-multiple-argument-constructor-ever-useful-over-a-single-tuple-argument-cons for more details).
Apple's intentional crippling of Mobile Safari (pwa.gripe)
•
Mobile web browser extensions and content blockers: Safari: Yes Chrome: NOPE
Note how it doesn't list which of these are Chrome-only non-standard APIs that Firefox doesn't support either. Oh wait. You don't care about small details like that. None of these Chrome shilling websites do.
•
Did you try opening the page? Each feature says which spec it's part of (e.g. "W3C Draft", "W3C Candidate") with a link to it. It also shows which browser implemented a feature first. Often it's Chrome, but sometimes it's Firefox, Opera, or even desktop Safari! Likewise, you can click on the Chrome icon to change comparison browser. Here's a list of features implemented in Firefox on Android but not in Safari on iOS (and therefore, not in Firefox on iOS either): https://ios404.com/?browsers=andff Fwiw, I've been a Firefox user for about 9 years. I would love to see Firefox be able to ship their engine on iOS. The main reason Firefox haven't implemented as many features as Chrome is that they lack the resources to. Anti-competitive behaviour has hurt them a lot, and being forced to use a sub-par, undifferentiated browser engine on iOS - the world's most valuable and influential OS, has played a big part in this.
•
Hi! Creator here (of iOS404) - you can filter level of standard and compare to FF Android (or compare to Safari Desktop, or any mix) instead if you'd like.
Businesses tend to relay costs onto their customers (someone has to pay the bills). - The app store tax - The extra work of maintaining at least 2 separate apps (iOS, Android, optionally(?) desktop web app) - Dealing with app store rules Some of these are not just costs. I have experience with native apps that have to make things worse for users (compared to the web app) or risk getting booted off the app store.
•
What outcomes are worse for users that arise out of you offering native apps?
Google has become the developer-focused company that Microsoft used to be, and I don’t mean that positively. Developers are lazy and want to inflict low-effort crap on users. Microsoft always made it easier to do that. Google is now doing the same thing. Offering developers more and more ways to cobble together box-checking functionality in web apps instead of developing proper native apps.
•
> Google has become the developer-focused company They’re the advertiser-focused company. Bluetooth and NFC aren’t being exposed for developers first.
You seem to be conflating my opinion of "iOS's lack of browser choice has the consequence of preventing Chromium from achieving total dominance" with some imaginary other person's opinion of "iOS's lack of browser choice is a benevolent act where good guy Apple valiantly defends the open web". I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't. (Not purely because Firefox is technically inferior, mind you; products don't compete purely on technical merit.) I think Chromium out-competing every other browser engine is a bad thing.
•
> I think Chromium out-competing every other browser engine is a bad thing. Hmm. I believe that Apple can compete with Google if they want to. They have the money, they have the marketing chops, they have the incentive ($20B search engine deal) and they are the default browser. (also, they have trained iOS users that Safari is the only default browser on iOS for 14 yrs by not allowing other browsers to be set as the default) All Apple has to do is actually compete , not just rely on their monopoly. I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?
•
> Hmm. I believe that Apple can compete with Google if they want to. I don't think that would happen. I don't have much faith in Apple's abilities in this area, and their incentives are structured such that the less viable web apps are as a replacement to native apps, the more money they get from their 30% cut. Again, your arguments would make sense if my opinion was: "good guy Apple valiantly defends the open web from Google out of the goodness of their hearts". But that isn't my argument. I don't care whether Apple could compete with Google if they tried. I care whether Apple would compete with Google, and they wouldn't. > I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right? WebKit isn't a browser monopoly, it has less than 20% of the browser market share. That 20% share is big enough to push web developers towards making websites work in browsers other than Chromium, but it's not big enough that there's a danger of web developers thinking, "everyone uses WebKit anyway so we won't bother testing on anything else". Sure, it's a monopoly on iOS , but I don't see how this is relevant to my argument. The web is bigger than iOS.
> The people don't like apps built with web tech Then why do most people spend > 90% of their time in a browser (or web-powered app) on desktop?
•
No choice.
•
Funny you would say that. Because businesses and users have only one choice on iOS: native apps, because the web app isn't viable (and/or available) on iOS.
Irrelevant, we're talking about mobile here.
•
How is that irrelevant? Isn't it important to ask the question "why did this thing work on desktop, but not on mobile?"
Project Nomad – Knowledge That Never Goes Offline (projectnomad.us)
•
For anyone wanting the video explanation from the creator, watch: https://youtu.be/P_wt-2P-WBk
•
>Knowledge That Never Goes Offline >What is Project N.O.M.A.D.? Node for Offline Media, Archives, and Data That's the first header, and the first sentence of the first paragraph, and I'm confused.
•
Two different uses of "offline", I think. From my own understanding: To "go offline" means for something to become inaccessible that was once accessible "online". ("Offline" is an adverb.) Meanwhile, an "offline" thing is one which is usable even without ever being "online". ("Offline" is an adjective.) So it becomes: > "Knowledge That Never [Becomes Inaccessible]" > "Node for [Accessible-Without-Connection] Media, Archives, and Data" But definitely confusing to put them right next to each other like that. You'd think a copyeditor would flag it or something.
•
My guess is >Knowledge That Never Goes Offline Means >Knowledge That Never becomes inaccessible to you While the next offline means you can access it even if you don't have access to a wider network. At least that's how I would read it.
Brute-forcing my algorithmic ignorance with an LLM in 7 days (blog.dominikrudnik.pl)
•
I'm always interested in write-ups when folks try new attacks on self-study. I will also admit that this part hurt my heart to read (vicarious embarrassment): > the recruiter mentioned I needed to pay more attention to code debuggability (whatever this means - I assume that under the corpo-language, they mean that I wrote invalid code)
Recently had a coding interview in which I was allowed to search online but not use any AI. On the first google search, the interviewer realized that the first result is now AI generated and said I couldn’t use anything from there. So I had to just click on different links and piece together what I needed from inside the pages
•
You have to build a house but dont use concrete mixers you must mix by hand to really see if you know the physics of concrete
I am quite passionate about algos, do lots of katas on codewars for fun, and done plenty of leetcodes. Then I had a technical interview when I was asked to implement a simple algo for the tris game (aka tic tac toe) and my mind was completely blurry. I was tired, i'm in eu and this was for a San Francisco startup interviewing me at their lunch time, very late in Italy. And generally don't like to be interviewed/tasked. Of course the solution is beyond simple, but I struggled even at brute forcing it. I can easily do these kind of exercises (and much harder ones obviously) for fun, but not when interviewed. I struggled with the same thing in University. I graduated with 104/110 even though I was consistently among the most prepared, and I learned to learn, not to pass exams (plenty of stellar performers didn't remember anything few weeks after exams). Once I asked a professor why did he grade me 27/30 even though I spent one hour answering with details on everything, including the hardest questions. "Because you never appear convinced when you answer". I get nervous, I don't like to prove my knowledge this way. I rethink constantly what I'm saying, or even how I sound. I forget how to type braces or back ticks. I did not have any issues when not interviewed, or in written exams, or during my research period when I published 3 papers that have been highly cited. But I am just not a fan of these types of interviews they tell absolutely nothing about the candidate. You interview me and you'll have the very wrong impression if you ask me to live code or white board. Meanwhile I've seen leetcode black belts spend most of their time logged on Tekken 7 on discord, consistently creating work and providing negative value while somehow always selling their high skills. I have found much more value in seeing personal projects, and OSS contributions. Never asked a single of these bs questions and never failed at hiring anyone. Not once.
•
> I am just not a fan of these types of interviews they tell absolutely nothing about the candidate. Unfortunately this is wrong and I have seen tons of data at 5 companies showing this. These kinds of interviews really do correlate well with job performance There is noise, but large companies in particular need a scalable process and this one works pretty well Startups shouldn't do this though, but the reason is the opposite of what you're complaining about. It's too easy to accidentally waste your time on somebody who is good at leetcode
•
I have never seen correlation. The most important thing about a candidate is whether he's gonna be professional and hard working. Technical interviews tell me nothing about it. Of course I can see large companies that have a high number of candidates relative to positions needing such methods, they can afford false negatives. But outside those cases personal projects and OSS contributions say much more.
•
How many people have you interviewed and hired? I have interviewed around 400 and hired around 20, and I've seen data compiled on over 100,000 interviews. I have never worried about a false negative, except DEI stuff pre-2021 Maybe this is a Europe vs US thing?
•
I've hired around 10 and interviewed around 50/60. Half the people I hired, I did so without any technical interview, I met them in coding communities and saw everyday their OSS contributions and skills. In any case I'm not debating your method is wrong, I'm just saying there's individuals like me that don't do well in these kind of situations/exams and can easily be false negatives. I'm also saying that this isn't rocket science, and in general trying to understand if the person is honest and hard working is much more important than his coding skills. I've seen way too many stellar graduates leetcode ninjas being just terrible at their job or completely uninterested. And in Europe it's hard to fire them.
Flash-MoE: Running a 397B Parameter Model on a Laptop (github.com/danveloper)
If you don’t care about turnaround time you can do that. Most LLM use cases are about accelerating workflows. If you have to wait all night for a response and then possibly discover that it took the wrong direction, misunderstood your intent, or your prompt was missing some key information then you have to start over. I don’t let LLMs write my code but I do a lot of codebase exploration, review, and throwaway prototyping. I have hundreds to maybe thousands of turns in the LLM conservation each day. If I had to wait 10X or 100X as long then it wouldn’t be useful. I’d be more productive ignoring a slow LLM and doing it all myself.
•
"If you have to wait all night for a response and then possibly discover that it took the wrong direction, misunderstood your intent, or your prompt was missing some key information then you have to start over." This exact problem exist for rendering, when you realize that after a long render an object was missing in the background and the costly frame is now useless. To counter that you make multiple "draft" renders first to make sure everything is in the frame and your parameters are properly tuned.
Everyone is focused on the bad 2 bit result but who cares? He says don’t use it because it’s bad.
•
If you don’t care about the output, why not reduce to 1-bit and only 1 active expert? It will be completely useless but it will be faster!
> I did not do a very long session This is always the problem with the 2-bit and even 3-bit quants: They look promising in short sessions but then you try to do real work and realize they’re a waste of time. Running a smaller dense model like 27B produces better results than 2-bit quants of larger models in my experience.
•
> This is always the problem with the 2-bit and even 3-bit quants: They look promising in short sessions but then you try to do real work and realize they’re a waste of time. It would be nice to see a scientific assessment of that statement.
 Top