The story of Wayland - restrict what applications can do in the name of "security" only to re-add the same thing in a compositor-specific way after years of pain inflicted on everyone. Wayland is fundamentally designed for the smartphone model and has no place on an open desktop.
I agree with the Wayland premise that having an old and hairy library everybody is afraid to touch is bad, but having those same capabilities implemented piecemeal and incompatibly by five (and counting!) compositor ecosystems in ways that aren't well-tested or well-integrated isn't better.
However, certain fundamental decisions of a language can be dealbreakers.
Requiring declarations on your functions and giving those declarations sigils so that they can be parsed quickly is an important syntax decision. Almost every modern programming language has converged to this idea.
Or take, for example, Lua. For me, personally, the 1-based-ness of Lua is simply a dealbreaker no matter how good anything else about it is.
For the "Lisps", I LOATHE the fact that you traverse lists and vectors in completely different ways--you can't just drop any container-ish thing into something that iterates/collects it. This is something that both Clojure and Racket seem to agree on--you have something that acts like a "collection" and you can walk across it the same way regardless of the specific type of collection it is. Of course, that is why a bunch of Lisp purists loathe Clojure and Racket while I like those languages. Shrug.
I find RAII (Resource acquisition is initialization) to be the source of all things evil if it infests a programming language. The popularity of C++ and Rust speaks to the quite large number of people who think my opinion is bullshit.
So, yeah, base syntax matters far less than it used to. But the engineering decisions that went into making that syntax correspondingly are far more important.
I agree with most of what you said, but I am puzzled about your claim about RAII.
Whether it is good for any kind of resource acquisition to look the same like an initialization is debatable.
On the other hand, I cannot see any counterargument to the principle that releasing any resources should not be done explicitly, but only implicitly, upon leaving a block (using reference counts for shared resources).
I doubt that you advocate for the use of explicit release commands for resources, which are a notorious source of bugs, so what is that you consider as not being the same as RAII?
RAII was a not very useful acronym that was just another form to say that the C or C++ programmers should never use the PL/I style of explicit free commands, despite the availability of functions like "free()" or "close()" in the standard library, but both memory and files and any other kinds of resources should be managed with automatic releasing.
I do not see how this sound principle can infest any language.
Obviously, I have seen examples of bad RAII implementations, like I have seen examples of misuse for any other programming principle.
> I doubt that you advocate for the use of explicit release commands for resources, which are a notorious source of bugs, so what is that you consider as not being the same as RAII?
Those are not the only choices.
Garbage collection is at one end of the spectrum--fully manually managed is at the other end of the spectrum. There is also another axis of acquiring/releasing allocation by object or acquiring/releasing object by pool. And, if you have it, there is the axis of allocate only at startup and never free until end of thread/application vs. allocate only at a frame of of time and then destroy them all at the next frame vs. allocate whenever and wherever.
RAII encourages the usage of lots of tiny individual objects allocated whenever and wherever all with their own lifetime cycles and makes understanding the memory usage of your application very difficult (this was the whole reason Rust was made--C and C++ made managing memory in Firefox ridiculously diffused and impossible to corral).
And, I'll be blunt, I think that Rust/Zig/C3 etc. are not the right direction in spite of the fact that I use Zig a lot. I think that the garbage collected languages cede far too much in terms of performance to the compiled ones and GC languages (like say OCaml) should be being used for systems programming more often.
For example, I think we would all be in much better shape against AI vulnerability scanners if more systems programs were in GC-type languages.
I think we can easily agree they are two entities (syntax / runtime) that feed off of each other. And I do agree that previously the syntax mattered more.
(I very much agree on Lua btw.)
Personally I am very disheartened. Surely algebraic data types should be universally a good thing and all PLs should gradually adopt them? But no, endless HN / Reddit threads bike-shedding.
@cImport is moving to the build system in an upcoming version (0.17, I think?). It's inconvenient, but it's unfortunately necessary.
The issue with @cImport is that when and the order the imports occur are almost impossible to define if you have multiple files and libraries. By moving it to the build system, the order now becomes deterministic and you can refer to it properly.
Your memory is faulty. AltaVista was always super fast--it never had the advertising bloat that the other ones had until the very end.
The problem AltaVista had was that it didn't scale when the Internet went exponential--so AltaVista would give you good search results until you asked current, topical questions. AltaVista relied on running a single, super-expensive stonking huge Alpha machine while Google ran on lots of commodity servers that spidered constantly.
This is inaccurate. When I was running AV operations around 2000, we were running on a couple dozen huge Alpha machines for the index layer and queries. We had a bunch of smaller machines for Web serving, and a high memory set of Alphas as a caching layer.
We also spidered constantly. A couple of those huge backend Alphas were dedicated to holding the constant spider index. AV had a well earned reputation for quick discovery, although I think Google wound up faster. We suffered a bit from maintaining separate indexes for the main corpus and recent pages, and I imagine Google handled that better.
But the period of time when our main index went to hell was the period of time when we failed to do a new main index crawl for several months. I won’t get into why that happened politically because my memory isn’t perfect and I don’t want to criticize anyone who won’t see this to stand up for themselves, but it’s absolutely the case that we let the index get stale.
And I will say that I think the execs were distracted by the idea of challenging Yahoo by buying a shopping site and a local news site of sorts and, unlike the Google of the time, they lacked the wisdom to focus on our primary product.
And now I fade back into the hedges, until the next time AV comes up… I suspect a high percentage of my HN comments are on this exact topic. It makes me sad.
And I still miss the AltaVista illustrated diagram (Java Applet) that would allow you to drill down and specialize the search results. No modern search has ever matched that, again.
That feature sounds amazing! I tried searching wayback etc but wasn't able to find any more details. Do you happen to know of any screenshots / deeper descriptions for it?
Perhaps we could nerd snipe Marginalia Search to add it :)
I was not a software engineer but yeah, I think so. Every now and then we’d have to go get Mike Burrows to do some consulting work to rewrite a bit more of the code in assembly.
Take one look at the mess of incompatible detachable cords that come with LED lighting fixtures from China to see what results.
They could have used bog standard IEC 320-C5 cables, but they didn't. Why? Because they wanted to cheap out on the conductor AWG and IEC 320-C5 is quite specific about the conductor gauges and current capacities.
So, the LED lighting manufacturers produced a bunch of cables that are in almost exactly the same shape and size factor as IEC 320-C5 while being just enough incompatible to not invoke the certifying authorities--all to save a couple pennies in copper.
> You could be right but I can think of numerous frustrating code jams in my past when we burned a lot of precious face-to-face time on fussy setup or other fiddly stuff.
Agreed, LLMs are particularly good at this kind of task.
For example: my windowing system on Linux would intermittently freeze. Diagnosing it was a pain--so I bounced the logs off the LLM. It gave me a couple of hypotheses and the commands to enable the correct logs for when it happened again. After the third time it happened, it pinpointed that a particular USB hub was causing the issue. I removed the devices downstream from that hub and haven't had an issue since.
The other LA (Louisiana) had lots of evidence to the contrary. If you force charter schools to participate in a lottery, they almost always come up worse than the public schools (there was a single exception).
We saw this happen in Houston. Many of the worst public schools suddenly "improved". It's a miracle! Oh, they did this by encouraging the lowest performers to drop out. Whoops.
And this is before we start talking about all the high GPA students who now all magically need IEPs (Individualized Education Plans) because it gets them an extra 50% of time on their tests. So, now you have your best students loudly (because these parents are active) soaking up lots of resources genuinely meant for your worst students.
> it consistently amazes me that few systems, teaching included, regularly poll their end users (students or employees)
That completely ignores the social and political aspects.
You need to understand that the people who have the authority to do so do not want to document bad teachers, ever. Documenting bad teachers makes political waves and principals and superintendents never want to make waves because that impedes their ability to both do their job as well as get their next job.
Even if a teacher is very bad, they may be well-liked or be an important part of the community. If you attempt to remove that teacher, they may rally support from the community that can be extremely noisy and inconvenient.
Entitled to your opinion, but this feels like an overly-complicated socio-political rationale for something that's equally explained by leadership laziness.
It's not rocket science to set up a continuous leader feedback mechanism.
> I spoke about this before, but jj has the Blub Paradox problem
It's not relevant. Don't try to convert git users--you don't need to. They're fine doing what they do, and the git backend store is acceptable. People who understand how broken git is will gravitate to jj with the lightest of prodding--give them a light poke and then don't harass them further.
The main difference is that I can teach jj (like I could teach hg) to normal people. And, because jj is based on the git store, they can operate in a Github world.
So, just teach jj to people who haven't yet broken their brain with git. Running on the git backend already gains most of the network effect, so don't proselytize the git people.
The ACA is, in fact, warmed over RomneyCare(tm) (a Republican, please note) from Massachusetts.
The fact that Kentuckians loved Kynect and hated Obamacare--which are the exact same thing (aka the ACA)--tells you everything you need to know about the Republican voting public.
Additionally, the fact that Democrats took a pro-corporate conservative policy package and rebranded it speaks volumes about how much daylight actually exists between the parties when you ignore the culture war rag waving.
You call that "the uniparty", while other here at the same time say they want less polarisation and more bipartisan consensus.
Make up your mind.
(I am old enough to remember that Obama convinced the Democrats that it was better than the existing system, and that small progress was better than keeping the status quo or waiting another decade to have maybe, someday the numbers to pass a better bill)
Although I think that there is FINALLY an actual spec for pointer warp. However, very few compositors support it.
reply