Lazarus does not support BPL. Android and iOS support are under question. Free Pascal devs for many years did not look into Ada, and looked into C++ more, and that made Free Pascal ugly. Delphi did not look into Ada either, but they looked into .NET instead, and that made Delphi not as great, but better than Free Pascal. Anything is better than C++. Delphi delivered controlled types, that was IIRC for many years in top 10 feature requests on Quality Central, until QC was purged. They call it "managed records".
Delphi has got inline const syntax. They talk about inline var, but from my Ada programming experience inline const is the real game changer. When there was only local variable block, some stuff was assigned inside loop. This stuff was assigned once per iteration, but since variable is declared outside the loop, it is considered variable. Now, when inside loop, it can be assigned once and made read-only. I have some doubts that Free Pascal is up-to-date with these changes.
Hi-DPI. Did not test, but questionable that Free Pascal got it right.
I'm not sure how you find Free Pascal "ugly" while Delphi not so considering that they're 99% the same language (up that to 99.9% when you compile Pascal code in "Delphi mode") :-P.
> Hi-DPI. Did not test, but questionable that Free Pascal got it right.
Free Pascal is the compiler and has nothing to do with Hi-DPI. Lazarus is what you probably have in mind and does Hi-DPI (in fact it can do Hi-DPI even with widgetsets like Gtk2 that themselves do not have support for it).
The IDE experience, they are the ones driving the language evolution, FreePascal follows, and the industry that cares about Object Pascal, usually only cares because of Delphi.
Don't get me wrong, FreePascal is great, but it hardly has a presence at big corporations.
If they no longer use Delphi, means they have long moved into either Java or .NET.
> they are the ones driving the language evolution, FreePascal follows
That is not the case, Free Pascal has improved the language before Delphi and Delphi followed, e.g. FPC added generics before Delphi and more recently it implemented management operators before Delphi.
One big annoyance though is that when Delphi does decide to implement some language feature introduced by Free Pascal they implement it using an incompatible syntax which is petty (at best). FPC then has to support both their own syntax (usually in OBJFPC mode) and Delphi's syntax (usually in DELPHI mode) to let people share code between FPC and Delphi.
I used briefly some 8 years ago, it is very good for getting full-native (including native UI toolkit) cross-platform desktop apps. It can build self contained binaries that just work.
My use-case was building a simple USB-stick-portable application for windows and it was great for that.
Over the past year, I've replaced quite a few of my Tcl/Tk GUI apps with versions built in Lazarus. Lazarus 3.x was a bit quirky for my tastes, but 4.x has been very good.
It's not quite the Delphi experience, but it's close enough that I could see myself using Lazarus for day-to-day development and being fairly productive with it.
It improved a lot and it is good. On Linux I think the default way to go is still Lazarus. But with Delphi you can buy more shiny polished things on top. So for commercial use Delphi is more relevant. And there are enough differences in compatibility, so you most likely don't want to deal with both at the same time.
But the LLMs are also not one-shotting it, or are they? I assume they have some ways to verify it, e.g. to visualize it (convert to PNG, then feed as vision tokens back to the LLM), or other ways, maybe also pure text LLMs have some ways to verify the result at least somewhat? And with such feedback loop they can iterate.
call me an optimist, but I believe that more and more things are getting more viable to do from the terminal. tools like jj remove the need in Git GUI because mental model and UX gets streamlined, and the AI craze incentivizes practically every company to create their own CLI
Small self-advertisement: as an alternative to dissect.cstruct, a fun side-project of mine (C parser + C interpreter in Python) can do a very similar thing:
I think the simulation in Cities Skylines is also quite advanced, or not? The simulation is much more the reason why it requires powerful hardware to run on, much less the graphics.
Can't speak on how demanding the simulation is/was. But on launch Cities Skylines 2 was extremely demanding in respect of its graphics due to very poor optimisation. This PC Gamer article summarises a more technical analysis, which is linked through
But yes, at launch Cities Skylines 2 was very heavily GPU bound, due to very unoptimized meshes and a poor culling implementation. I haven't profiled it afterwards, but from what I've read they've optimized it enough that on most systems the limiting factor is now the CPU.
Thank you for your analysis! Apologies for not linking to you by name but I thought I'd keep it light and refer to the PC Gamer summary, which does link through to you as well for those who would be interested.
Cities Skylines has pretty decent simulation and it uses quite a bit of raw CPU horsepower, but it only really shines with tonnes of mods (just like SimCity 4 before it).
Realistic traffic is always the bane of these simulators.
I don't fully understand why it is a standalone project. The readme discusses this: DwarfStar 4 is a small native inference engine specific for DeepSeek V4 Flash. It is intentionally narrow: ...
I think the only bigger difference in DeepSeek V4 vs other models is maybe the type of self-attention. And that leads to: KV cache is actually a first-class disk citizen.
But I still feel like those changes could have been implemented as part of some of the other local engines.
I also assume more models will come out, not just from DeepSeek but also from others, and they might share similar self-attention approaches, that would benefit from a similar KV cache implementation.
Check the readme better. The code overlap with ggml is very small, but a few kernel and ideas and the quants code were taken. Still the project connection with llama.cpp and ggml is huge and also present in the license because it's not a matter of code but of a whole ecosystem built, engineering lessons on how to do things and many other stuff. Also the readme explains exactly why a vertical inference system for a single model is the goal of the project.
Which makes sense, the amount of PRs llama.cpp receives from authors who have no clue what they're doing and can't even answer simple questions about "what they did" is staggering, must be very exhausting to have to figure out "is it worth replying to this author?" for every single PR.
You don’t adopt an unofficial fork just because it exists. Showing up with a clone isn’t the same as meeting the standards required to be part of the original project
That might have been a possibility if brought forward in an open and reasonable way, a bit harder to trust someone once they just vibe adopted the project someone was working on for decades and didn't seen an issue with that. Also "just" is doing a lot of heavy lifting there.
The "author" couldn't tell you the why behind any of the original design decisions. It's vibecoded, they never had to know. They would be a terrible teammate with no actual understanding of the project.
Maybe there are trust issues now?
I certainly would refuse to work with someone who comes and steals my brand, pretends I am on board with this and refuses to comply even after being called out.
Nobody else has pointed this out, but a MacOS port of Notepad++ actually goes against some of the branding. Notepad++ very much markets itself as a lightweight and speedy thing that uses the low-level Win32 API directly. It is not just a native application, it is a Windows-native application. Porting it to macOS requires a level of care and expertise which is tantamount to changing the entire organization.
I am sure the Notepad++ team is perfectly fine focusing on Windows expertise and has no interest in bringing in the overhead of another OS. If a serious macOS expert wants to do that, they can fork the project with a different name.
BTW look at the GitHub issues. This is a lazy developer creating a slop project. It would be stupid to bring this incompetent and dishonest person on board.
I'm curious: In the current moon flyby, how often did some of these fallback methods get active? Was the BFS ever in control at any point? How many bitflips were there during the flight so far?
The same question I wanted to ask. I'd be very curious to learn about their post-mission analysis to find out how many bit flips occurred and how many times this redundant system prevented the mistakes from causing issues.
