That’s not an accurate take. Microsoft has had a monopoly on the PC desktop OS. Anyone writing applications for users was targeting Windows and using Microsoft. To call most of these developers “not serious” is quite and overstatement. This includes all PC game developers, DAW, CAD, Adobe…?
Azure expanded the Microsoft franchise, and provides another prong to their whole integration story just like cloud AD services and online Office 365 provide another way to stay integrated into their ecosystem.
Yeah, they needed to work on their image somewhat, but their image never negatively impacted them
I love Zed. I was a fan of Sublime Text, and could never get used to VSCode. I thought I'd try Zed a try when it was still extremely raw, before the AI integration, and I loved the simplicity and speed almost immediately. When they added better python linting features, I switched, and haven't used anything else. I know that there are many anti-AI folks here, but I feel lucky that we they added the Zed Agent, and all the integration. It's been great not having to switch back to VSCode for copilot.
That's what I just said. There is zero value to me knowing these numbers. I assume that all python built in methods are pretty much the same speed. I concentrate on IO being slow, minimizing these operations. I think about CPU intensive loops that process large data, and I try to use libraries like numpy, DuckDB, or other tools to do the processing. If I have a more complicated system, I profile its methods, and optimize tight loops based on PROFILING. I don't care what the numbers in the article are, because I PROFILE, and I optimize the procedures that are the slowest, for example, using cython. Which part of what I am saying does not make sense?
I agree. I've been living off Python for 20 years and have never needed to know any of these numbers, nor do I need them now, for my work, contrary to the title. I also regularly use profiling for performance optimization and opt for Cython, SWIG, JIT libraries, or other tools as needed. None of these numbers would ever factor into my decision-making.
My first thought was that pixels are never square. Squares are an artifact of nearest sampling to another grid. I suppose pixel art assumes knowledge of this final grid, but most media doesn’t?
Furthermore, the referencing of a raster can assume any shape or form. It makes some sense some signals are optimized for hardware restrictions.
Another interesting example are anamorphic lenses used in cinema.
I wouldn't call advanced movement "speeding up Quake". Speed in Quake and other FPS is an important factor that influences what you based on the speed that you have. Bunny hopping, air control, rocket jumps are not as useful when the base speed goes up. Also, less maneuverability, like in Quake 2, and bigger maps, mean that you have to be more judicious about your next move, and plan ahead more, stock up on more items, etc. There is an important balance to these things.
Anytime this topic comes up, I ask: Why not both? I don't want to modify my SQL strings every time I change a column. Django ORM lets me combine custom SQL snippets with ORM code. I never hesitate to use custom SQL, but its just not a reasonable default for basic CRUD operations that my IDE can autocomplete. Not only that, but also provide nice feautures pike named arguments, walking relationships, sanitizations, etc. At the same time, I can do a UNIONS, CTES, anything I want. I just don't understand why it's worth arguing against ORMs, when no one is forcing you to stop using raw SQL.
I completely agree, it is absolutely essential to understand what SQL is emitted, and how SQL works. Perhaps the strawman argument against ORMs is that they preclude you from knowing SQL. They don't.
I don’t see splashes of primary color as more artistic. Anyway, what if you just ask it “more coarse”? I see impressive depth in the latest outputs, but as with all technically proficient performers, you might just have to consciously scale it back.
You would think, but not in a way that matters. Everyone still compresses their mixes. People try to get around normalization algorithms by clever hacks. The dynamics still suffer, and bad mixes still clip. So no, I don’t think streaming services fixed the loudness wars.
Perl is what killed Perl. I have never had as many "tear my hair out at 4AM" debugging sessions as I have had with Perl, because I missed some weird character somewhere.
Part your point about enterprise and mission critical software is that Microsoft is well aware of their biggest customers. Whatever agentic bloatware they will be adding here, it will absolutely be configurable via group policy.
I agree that we should get a successor, but if it got deprecated way back, I think we would have more likely gotten one. For just downloads, I have used apache and nginx directory and file listing functionality with ease.
I'm genuinely curious about that. But, this says a lot more about how different these standards are. FTP really needed a good successor, which it never really got. So, there is a strong use case, but technical deficiency to the protocol. So, FTP was overcome by a meriad of web forms and web drive sites, as a way to fill the gap. Still, resumable chunked uploads are really hard to implement from scratch, even now.
Dropping XSLT is about something different. It's not bad an in an obvious way. It's things like code complexity vs applicability. It's definitely not as clear of an argument to me, and I haven't touched XSLT in the past 20 years of web development, so I am not sure about the trade-offs.
Also, the protocol is pretty much a holdover from the earliest days, before encryption, or complicated NATs. I remember using it with just telnet a few times. It's pretty cool, but absolutely nobody should be using FTP these days. I remember saying this back in the 2005, and here we are 20 years later, someone still lamenting dropping FTP support from a browser? I think we're decades overdue.
I love the visualizations on that page. There were some other cool interactive visualizatiosn on bl.ocks.org, but sadly, that site has be shattered. This is the closest I could find:
Russia was primarily an agricultural exporter, but it was most certainly a capitalist society prior to revolution. It bought and sold many things, and was an industrial nation, on par with many others in Europe, with a capacity to build war ships, tanks, artillery, trains and so on. It had other tremendous inequalities, but without factories, without lower officers in the navy and army, without the first revolution where the capitalists took over, there would be no second revolution of the bolsheviks, or soviets.
I completely agree, real world queries are complicated joins, aggregations, staged intermediary datasets, and further manipulations. Even if you start with a single coherent 650gb dataset, if you have a downstream product based on that, you will have multiple copies and iterations, which also have the reproducible, tracked in source control, and visualized in other tools in real time. Honestly, yes, parquet and duckdb make all this easier than awk. But, they still need to be integrated into a larger system.
What if it was 650TB? This article is obviously a microbenchmark. I work with much larger datasets, and neither awk nor DBD would make a difference to the overall architecture. You need a data catalog, and you need a clusters of jobs at scale, regardless of a data format library, or libraries.
Is it better or worse than alternatives? Where else would a suicidal person turn, a forum with other suicidal people? Dry Wikipedia stats on suicide? Perhaps friends? Knowing how ChatGPT replies to me, I’d have a lot of trouble getting negativity influenced by it, any more than by yellow pages. Yeah, it used to try more to be your friend but GPT5 seems pretty neutral and distant.