Yeah I wonder why they aren't used for neural networks. It's been claimed they'd require far less power and they'd offer better accuracy and faster computations, although I am unable to verify that claim.
NASA requires 15 decimals of pi for interplanetary navigation. On the range of 16 bn miles to Voyager 1 it gives them calculations being off by 0.6 inch. For universe-sized circles they need 37 decimals of pi.
Trying to remember 100 digits of pi won't give you any advantage in cognitive functions apart from memorizing 100 digits of pi, for a little while. Better spend your time elsewhere.
I never really understood the craze for the overpriced Apple products. After many years of using PCs with Linux and Windows, I got forced to use a MacBook Pro as the company laptop and I found it hard to use. The OS is so limiting, Finder so crappy, oh my. There are some advantages, like the hardware is good, but on the other hand there are countless tiny issues where "Apple knows better" such as tying mouse scroll direction to the trackpad direction which is awkward for me. And now this what you're describing. So no, thanks, I'll stick to ThinkPad.
If you don't know where to find the checkbox to disable natural scrolling (you can ask Apple's built in search, even) I don't think anyone should be listening to your opinion on Apple.
That's unnecessarily harsh. Try disabling mouse acceleration without Googling anything; where's the search entry for that? Why is there no Preferences option for it?
Windows, KDE and GNOME all expose this as a GUI toggle. macOS doesn't.
You don't buy Apple because it's good. You buy it because it's what the cool people use.
Imagine applying for a SF startup job and letting them know you use a Windows computer.
At best they will politely tell you to fuck off. But they might blog/X about the idiot Windows user who imagined they could be cool enough to work for them, all coated in a plausible "a craftsman takes care of using good tools, sharp knifes, ..."
Apple hardware is good, but not uniquely good. There are plenty of other good computers out there, Apple hardware isn't in some special tier where nobody can touch them.
I had a surface laptop, it was fine, not as good as a MacBook imo.
Had a razer laptop, it was good, got very hot though.
Had an X1 Carbon Extreme that I liked, wasn’t as good build quality or screen or camera or trackpad as my MBP from work at the time though, was still expensive af.
What are you thinking of that’s better than a MacBook Pro?
By that logic, why don't Macs outsell the sum of Windows machines? If people buy Apple devices for the quality, Macs should outsell Windows machines 5:1.
In reality, I think it's well understood that 95%+ of customers (for Apple, Google and Microsoft) don't make any evaluation of device quality. They buy whatever they see their peers use, because they want to identify with the [luxury|convenience|hardworking] lifestyle of their comrades and idols: https://en.wikipedia.org/wiki/Keynesian_beauty_contest
> By that logic, why don't Macs outsell the sum of Windows machines?
That’s incorrect, because I never said that everybody buys a computer because of hardware quality, or any other reason. All I said was that Apple has great hardware and it’s part of the reason for their success.
Dell, Lenovo, HP sell more units than Apple, but they likely don’t make more profit on that segment of their business.
There is no contradiction. I agree Apple hardware is good. But it's not why you buy it (well, maybe you personally do, but you are not representative of the median Apple client)
If it was that simple mainstream Linux success would be one good marketing campaign away.
Their hardware is really good, their software is fine — at least as good as all the others to the average user I think, the integration between their products is good, and their marketing is obviously top tier.
I don’t think they’d be as successful if their products were not premium hardware.
I’d love an arm based laptop with a great screen and trackpad running Linux for work.
Do you have any sources for this? I agree that people tend to follow their peers, or seek things that communicate a higher social status, but like, Apple's hardware just is also very good, and that could easily be why someone stays with them, even if they were prompted by status.
Yeah that practice is not unheard of. I can easily imagine having a ready-made device to desolder the original chip out of Raspberry and solder another one, of poor quality and/or counterfeit, and then sell that modded Pi for profit. Heck, remember fake SD cards, USB drives etc.
I'd happily see performance, latency and stability of your allocators in massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.
Writing allocators for domain-specific access patterns is easy. Writing a general-purpose high performing, stable allocator with bounded P99 latency is hard.
Give your friend, Dunning–Kruger, some better pills to keep him from speaking through you.
You're correct, but his point is that you don't need to solve the generic problem. Solving the generic problem is very hard. Grug doesn't like solving hard problem. What does grug do? Solve five easy problems. Make an arena for the short-lived objects, reuse the objects, use generic multithreaded malloc for the rest. Grug happy.
I guess the point was that before you consider using a different allocator you should rule out a custom one.
And that's rather hard, because a general purpose allocator makes all decisions based only on the requested size. This is a very simple interface and such a tool is worth having. But a custom allocator can both bake in a specific scenario and provide more nuanced interaction.
>massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.
My first thought would be to use per thread pool allocators.
Two things. One is that to remind folks that PostgreSQL has used a tiny form of "artificial intelligence", that is GEQO - Genetic Query Optimizer, since 2001.
Second. How would that LLM-based query optimizer work in a real-world 10,000 qps ERP system with very large shape of queries? I'm not saying it's useless, it just won't replace a real query planner soon. Latencies would skyrocket.
I'm also quite skeptical of performance/determinism over a real world load but
if I'm not mistaken, a 10 000 qps with large shape of queries would not benefit much either from genetic algos, would it?
I feel like I have to remind people of this quite often, but the history is such that npm was lightweight at one point, bundling wasn't a thing, and while `isodd`/`iseven` are of course silly, things like `isarray` were not functions that existed back then (we didn't have Array.isArray). `typeof [] === 'object'` in JS, so e.g. my package `is-arrayish` checked for a similar structure to an array (whereas Id guess `isarray` checked for the prototype). `isarray` failed for the `arguments` keyword, which was needed for variadics before argument spreads were added to the language I believe in ES5.
So of course they don't make sense now. But they were created for a reason. Before even Markov chains were a fad - let alone LLMs - we were trying to be as efficient as possible and maximize code reuse I stead of writing the same helper functions over and over again. That's what you're seeing.
Additional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.
Yes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.
> Ut oh, your code is now broken because isOdd(2^55+1) returns true now...
I think you messed up this example. Whether I literally use "2^55" with XOR or replace it with "2*55", that version of isOdd returns false.
False for isOdd(58) is obviously correct. (Also thanks C for permanently screwing up the precedence of bitwise operations because you didn't want to break some existing programs in 1972.)
False for isOdd(36028797018963970) is also correct, and if you expected to send in a different number the bug is in the "+1" not the isOdd.
But there's no bug in isOdd. You're sending the number 36028797018963970 into it, which is clearly even.
Putting extra code between the parentheses of the function call doesn't make it the function's responsibility. As nice as it would be for debugging if you could stuff your entire program inside of isNaN((function(){ /* your code here */ })()) and force your browser vendor to fix all problems.
Despite what most JavaScript implementations will tell you, 2 to the 55th power is 36028797018963968, and adding one to that value is 36028797018963969. That's clearly odd.
There is no extra code between the parens. I just put them there so there wouldn't be any question as to operator precedence. I do see now that hn ate my double star, but I think you know what I mean since you told me the value that is spits out when you do the exponentiation
You have a plus and an exponentiation in there. That's code.
var n = 2**55 + 1
console.log(n)
isOdd(n)
n is 36028797018963970. isOdd(n) is giving you the right answer. Putting the +1 inside the parentheses and talking about calculators is a sleight of hand that lets you pretend isOdd gets an odd number, but it doesn't. No odd numbers are around by the time isOdd actually does anything.
The problems are in + and/or our expectations of +. It does not output 36028797018963969, and we must acknowledge that.
I don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be.
It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.
I was definitely saying it at the time. But I wasn't embedded in the ecosystem, it was very much "those JavaScript guys are nuts, why would they do this?"
There’s a bit more nuance as to why. It’s not fair to say that the average JS dev is reaching for a package like is-odd/is-even.
Years ago when npm was just getting started there was a lot of experimentation and land grabbing for packages. A few “prolific” developers were pushing these tiny utilities and then using them in their own projects which ended up being required as deps in other projects and then snowballed into is-odd being included in webpack at some point (I think I have that timeline roughly correct).
It’s still a crappy problem for sure but it’s not fair to paint most JS devs with a brush so broad.
Everything that touches JavaScript in the corporate world feels broken.
Look at any full stack job post. It’s a mess of tech stack nonsense on the backend for people who are terrified of JavaScript and a layering of framework madness on the frontend for people who are still terrified of JavaScript. So it should be no surprise to see packages like those in common use when people aren’t really writing, or even reading, the real code anyways.
That is just the coding aspect of it. There are many additional challenges to working with a bunch of cowards whose primary job is to pretend to be something they clearly aren’t.
There’s not much evidence these are being used, only that they are dependencies for something else; that’s why the download numbers are so high.
I wouldn’t say it’s broken, I’d say there are tradeoffs, and devs have known this and discussed it since the start of npm or any package manager. You automatically get some bloat when you use other people’s software. That’s the downside. The upside is you don’t have to write the code yourself and you can create things more quickly by not solving problems that others have already solved.
It’s worth noting that AI has some of the same tradeoffs. The quality of what you get is still proportional to your prompting & reviewing effort, and spending low amounts of effort often results in similar amount of bloat.
These packages are basically memes at this point... Those download figures cannot be accurate for real production usage.
I don't believe any programmer is actually using these. isarray and left-pad are at least functions that didn't used to be in the standard library, to slightly excuse them.
Actual programmers do indeed use these packages, and in large numbers. I was in the unfortunate situation a few years ago of hiring a couple of interns (both juniors in a decent CS program) who relied heavily on these types of packages. They honestly thought that it saved them time and they didn’t seem to comprehend the bloat they were adding to otherwise simple code that they could’ve written themselves in 30 seconds. NPM trained a generation of programmers to look for packages rather than learning basic scripts.
I would not bet on that assumption. I have seen some wild code over the years from devs. With 'ai' type coding going on now too you may see them be used even more.
Opus and fable both are pretty judicious about bringing in dependencies, at least for me. They often argue against and and write even decently large modules to avoid pulling stuff in.
They never install packages for me and love handrolling large amounts of e.g. parsing code where a library exists. I have to keep telling them 'look for a large popular dependency' when they start writing huge functions that obviously already exist.
Was doing something with OSM the other day and Opus basically started reimplementing NetTopologySuite.
I would've actually thought AI would slightly improve upon this situation. At least in my experience claude seems to write a lot more little utility functions itself rather than reaching for a package from npm to do something. Requiring an `npm install` before getting something working risks triggering a permissions gate.
While I supported that idea of Rust coreutils, this your experiment showed me how bad it is. My results are totally different, but not what I expected (edited out long strings of "a/a/a" for brevity). I wouldn't call it stable...
root@71a8c5a6c5e3:/# mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
mkdir: File name too long
root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
gnumkdir: cannot create directory 'a/a/a/.../a/a': File name too long
root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((3 * 1024)) | tr -d '\n')
root@71a8c5a6c5e3:/# rm -rf a
rm: cannot remove 'a/a/a/.../a/a/a': Directory not empty
root@71a8c5a6c5e3:/# gnurm -rf a
root@71a8c5a6c5e3:/# rm -rf a
root@71a8c5a6c5e3:/#
And then they plan to move to a new Rust-based NTP. No comment...
reply