It seems that today we can achieve similar functionality in fundamentally different ways (WSL, WSL2/virtualisation, Cygwin, etc.) What in your opinion is today's closest solution to colinux? and why we don't see such clever solutions today?
WSL2 is analogue to coLinux and WSL1 is analogue to Cygwin. WSL2 is definitely what you want in place of coLinux. However, both have merit in what they can achieve depending on the circumstances. There is long thread on Github about the switch between the two, with many people asking to maintain both.
Yep, the only advantage I see with using ASCII control characters is that you can save a few bytes depending on the content. To make this approach robust, escaping is still needed.
Zed is supposed to be a lightweigh and fast text editor. That was my hope when trying it. This is not the case. When I was editing some JS or HTML file I noticed that my laptop is quite warm. I checked all processes and there was some node process taking up 100% of one of CPUs. It was some language server running in the background in some non-efficient way. The problem with Zed is that its mission is to be "engineered for performance", while in the background they cut corners and run some heavy unoptimized stuff. I think this is not a right strategy, even cosindering it is still in beta.
One problem with Raspberry Pi displays is that not all of them provide vsync signal in SPI mode. That leads to high CPU usage (due to very high frame rate) and its generally inefficient. Choose your display carefully.
I think this is the case: when you run your pipelines at scale you want to standardize and simplify some repeatable aspects to lower the cost of managing them. You may also want to be orthogonal to orchestrator engines (or triggering engines) and avoid getting too opinionated and inflexible in the future. So this framework is exploring some sweet spot between raw spark pipelines and low code etl engines.
yeah though a lot of these fall for a variant of the "universal standard" conceit joked about in xkcd. All these low-code solutions suck, so we'll build our own in-house that surely won't have the same pitfalls..
Some years ago I compared those boilerplate removal tools and I remember that jusText was giving me the best results out of the box (tried readability and few other libraries too). I wonder what is the state of the art today?
Mamba is supported in llama.cpp so should be (edit - apparently it's not strictly the mamba architecture, it's a mix of mamba and transformers, so it looks like it would have to be ported to llama.cpp)
I’ve often heard people mention that Delphi was a superior RAD GUI experience than Visual Basic, but as someone who’s never used it, what is it that made it so great compared to VB or other GUI builder type tools (eg Qt Designer)?
The pascal language requires things to be declared in a certain order. It's a bit awkward some of the time bit it enables the compiler to work in a single pass. This meant that running an application was extremely fast by any standards and this really made it stand out compared to other development tools out there.
VB created applications that had to ship with a shared runtime library. Windows wasn't great at versioning these libraries so developers often shipped their own VB runtime with their executable. The executable was small and the runtime was comparatively huge which had a negative impact on user perception when downloading the installers.
Before moving on to Microsoft in 1996, Anders Heilsberg was the Chief Engineer at Borland that oversaw the development and release of Delphi 1.0.
For years, VB felt like an application that could make deployable versions of itself. Delphi felt like a programming environment that compiled code into applications.
After Heilsberg moved to MS, a lot of improvements were made in VB that utlimately made Delphi less attractive, especially during Borland's strategic waffling known as "The Inprise Years": https://en.wikipedia.org/wiki/Borland#Inprise_Corporation_Er...
If you want to get a feel for what it was like then check out the FOSS clone "Lazarus".
> After Heilsberg moved to MS, a lot of improvements were made in VB that utlimately made Delphi less attractive
Well, not actually. With Anders' move to Microsoft, VB6 (aka, VB "classic") was discontinued. Microsoft supported Visual Basic syntax on the .NET runtime, but the vast majority of VB programmers considered this to be a different language because developing for the .NET Framework (remember this is ~2001) was a huge departure from VB Classic.
Many VB developers petitioned Microsoft to open-source VB6 or continue releasing improvements on it. Microsoft did not and chose to continue with their .NET + C# strategy.
There's a bit of a gap there though between 1996 and Visual Basic classic being discontinued. VB.NET came out in 2002 but VB6 was supported until 2008.
VB5 in 1997 and VB6 in 1998 really closed the gap with Delphi from what I remember.
VB5/6 had native code compilers. Performance wise, the gap was reduced.
But it still was only object based and not full OOP, VCL was much better in all respects, so were the GUI builders. The component ecosystem was much better, despite having a much smaller user base. I prefer not to use Object Pascal today, but back then, it was superior to using VC++ or VB.
VB6 was my last VB. It came at just the time when getting a computer onto a network to download and install a giant distribution was touch and go. The building where I worked didn't have networking in the labs, the "labs" were whatever space we could find, and the "lab computers" were old cast-offs retired from office use. It meant that supporting VB.NET with a brand spankin new networked computer wasn't a safe assumption.
At the same time, I was playing with Linux at home, and wanted tooling that could run on either platform. I learned Python at home, and then made the switch at work.
One of my last VB6 apps, thousands of lines, has been running in the plant without issue for 15 years. On one occasion I had to bump up the declared sizes of some fixed length arrays.
As for GUIs, I never found anything close to VB, but also decided to just write a thin wrapper around Tkinter and let my layout be generated automatically by default. I haven't missed laying out my GUIs, which were always a hodgepodge anyway.
> After Heilsberg moved to MS, a lot of improvements were made in VB that utlimately made Delphi less attractive, especially during Borland's strategic waffling known as "The Inprise Years": https://en.wikipedia.org/wiki/Borland#Inprise_Corporation_Er...
Having worked with both Delphi and Visual Basic, I've found that Delphi had the edge, especially for professional apps. Its use of Object Pascal meant you got compiled, efficient code right out of the box, and it didn't need an extra runtime like VB.
The VCL component library in Delphi is still unmatched in native code – very comprehensive built-in (and commercial) components, and customizable. Plus, Delphi's database connectivity was unparalleled and can be setup in the designer where you could see data queried and returned live in your grid component!
Delphi also supported advanced language capabilities (when compared to VB), like inline assembly and pointers, which were essential for low-level optimization or system hacking. The robust error handling in Delphi was another plus compared to VB's older 'On Error' style.
Interestingly enough, the VB6 runtime has been part of Windows for quite some time, to the point that my old VB6 projects still run fine, while my experiments with VB.NET in .NET Framework 1 and 2 currently don't, since the ringtone isn't preinstalled. (granted, moving those to modern .NET is probably fairly easy)
Few things that made Delphi great: for one thing you could develop all sorts of apps in Delphi - from system management apps, to database heavy apps, to editors, to games etc.
1. The component architecture was just great - I have yet to see any language/platform with a more sophisticated component structure even now.
2. There were all sorts of free and commercial components that you could download and install into the IDE and have it running in your application in next to no time. ActiveX etc didn't even come close to the level of integration and speed that the Delphi component architecture provided.
3. Components could be loaded into the UI during the design time itself and you could see it functioning directly within the IDE when you place it on your form. Example: You could connect to a database, run a query, put that into a table with all sorts of sorting and navigation functions and you could see this working even without compiling the 3pplication.
4. It was trivial to develop components for Delphi - even though it was so sophisticated. You could develop one in about 15-30 minutes.
5. The compilation speed was just insane. It just blew everything else out of the water and so you could do fast compile+run cycles.
I agree with everything except 4. It was easy to develop trivial components, but anything more complex and you'd have to do some serious work and the IDE would crash on you on mistakes and there was no way to debug your component live. I can't imagine the pain those DevExpress developers went through to make that VCL data grid of theirs.
I wrote a neural net ML app in the 90s using Delphi.
VB was easier to start but Delphi was nearly as fast to build, code was compiled (fast!), Object Pascal supported OOP and the UI features like visual form inheritance I have yet to see implemented anywhere else.
Visual Basic 6 was quite limited, it was a programming language designed for doing applications.
Delphi, with its Object Pascal roots, was(is) a systems programming language that also happens to have a nice RAD tooling for GUI applications.
Put in another way, it didn't own anything to C++ in capabilities, and had VB like tooling.
VB had to wait for version 6 to support AOT compilation and being able to implement its own COM based controls without depending on C++, and even then it only supported a subset of COM features.
Meanwhile the GUI framework being used by C++ Builder is actually written in Delphi.
1. The language was better for big apps (statically typed, more powerful, lots of features like proper exception handling). It supported proper multi-threading and better Win32 interop, which in practice you often needed for advanced effects in both Delphi and VB.
2. The documentation was excellent and always reachable from anywhere in the IDE. It was all local of course so if you wanted to know about something - a control, an API, a part of the UI, whatever - you just pointed at it and pressed f1. Help would appear immediately with low latency. It also came with a big pile of yellow and blue covered books that taught you everything you needed to know.
3. The UI was well optimized with things like tabbed editors before tabbing became popular. It was made up floating but dockable windows, sometimes this was annoying but other times it let you keep things on screen.
4. Very good support for database connectivity.
5. The ecosystem was more coherent. VB wasn't usable for many advanced tasks so VB devs relied heavily on components written in C++ (OCX controls). Delphi was more powerful so components were often written in Delphi itself, with all the attendant advantages.
6. "Components" were more powerful than ordinary libraries of the type you get today - you could install a component into the IDE and it'd appear in a components picker at the top. You could then immediately drag and drop them onto a "form" (window) and begin configuring it with an interactive property and event UI that was always present on the left. This worked even for components that were not UI components, for example, you could drag/drop a timer from the component library onto a form, see all the properties and configure them visually, and then double click on the event to be taken to an editor window with the event handler already written out for you.
7. There were lots of little quality of life things, like it came with some stock icons for buttons.
Last time I used Qt Designer was the KDE2 days, it's almost certainly better than Delphi by now.
Versus the way we do things today, some stuff was better and some is worse. Delphi was primarily a wrapper around Win32 so apps written in it weren't portable. Back then it didn't matter of course, Windows had a monopoly. That meant it inherited Windows' limitations - UIs weren't responsive, styling barely existed, typography was limited, and the deployment story was nonexistent. That's why you keep seeing references to how great it was that Delphi made statically linked EXEs; same reason people like Go today. Operating systems suck hard at deployment, one of the things that eventually pushed people towards the web. In the grand tradition of platform devs ignoring deployment entirely, Borland never fixed it even as the web ate their lunch along with Microsofts.
On the other hand, the components model was pretty nice. Being able to configure libraries using a simple auto-generated GUI made them often much easier to use.
> The ecosystem was more coherent. VB wasn't usable for many advanced tasks so VB devs relied heavily on components written in C++ (OCX controls)
Until VB 6, which introduced AOT compilation based on VC++ backend, and creation of OCX in VB itself.
To this day, one of the easiest way to do COM on Windows, even better than .NET Framework (.NET Core made it harder, yet another thing that Framework does better).
In version 6, you could chose what compilation model, classical (p-code) or the new AOT backend.
Compiling BASIC to machine code is how it was born after all, the interpreters came to be in 8 bit machines, due to their hardware constraints.
Besides, Microsoft already had similar experience with a dual compilation model in Quick BASIC.
And not to leave this being my opinion only,
"Microsoft Visual Basic allows you to compile your applications to fast, efficient native code, using the same optimizing back-end compiler technology as Microsoft Visual C++. Native code compilation provides several options for optimizing and debugging that aren't available with p-code. These options are traditionally called "switches," because each option can be turned on or off."
I always thought that the primary reason that native apps lost to the web was deployment, something that is so easy to fix and yet OS people are completely blind to it.
