No piece of art exists without context. With AI there is no context, no meaning, no relevance. A pretty image by itself is just that - a bunch of bytes displayed on device of your choice.
> A pretty image by itself is just that - a bunch of bytes displayed on device of your choice.
Isn't this the majority of the industry? Sure, maybe there are a few artists that can do profound work with context, meaning, etc. But when you're doing book covers for airport novels, you don't need any of that. Or when doing a website with a few images? You need a result that's good enough at the cheapest price. AI generated content is great for that.
There's always some sort of context, this is what allows something to exist in the first place. And even if the artist may define that the context is not “valid”, the audience can make anything it wants with it.
There are also such things as art direction, vision, and style. Even if AI can mimic style with style transfer, it will never achieve greatness this way.
You can apply an AI-powered “Starry Night” filter to any picture, but do you really think Van Gogh would draw something like that?
I doubt that. Unless you specifically target win32 and its non-core replacements (like classic full-fat C#) there is nothing that VS has to offer that outdoes other programs.
For the non-web world specifically, the part that was Windows Server and Windows Desktop is simply a dead end outside of niches. And within the niches, comparisons are not all that relevant since... they are niches. If you have a specific job for a specific tool, then trying to compare that with something that does not meet those specifics isn't all that helpful.
Most of my C/C++ work that remains doesn't even target windows anymore since there is no purpose for it. The super small subset that does is just things like device drivers, and that's more a property of the OS than of the project itself.
I do not think Windows desktop is a niche. It doesn't have the same percent of development it used to, but in absolute numbers it didn't decline.
Many people are using the Windows desktop and many old and new software is being developed.
Speaking of which, I feel the need to rant a bit: developing for Windows using QT is much more nicer than with any MS framework. MFC is a nightmare. Windows Forms was deprecated in favor of WPF which no one cares about. From C# you can't use Direct X or Vulkan with ease.
Maybe MAUI will bring a better experience. But they need to do something for C/C++, too. Maybe buy the rights to use QT and integrate it with Visual Studio if they don't want to develop a good framework. Or buy the framework from Embarcadero (the one used by C++ buulder). But don't force people into MFC mess. I presume that even their own developers hate MFC with passion.
Winapi was ok in the 80s. MFC was ok in the 90s but we are in 2020s.
That's probably why people 'like' certain tools, they are still working inside that context or environment and then there are no other tools that do that thing well.
But that doesn't make the tool a great tool in absolute terms. That is also the problem with this type of comparison, some people come up with arguments that are tangential at best. If you use literally anything else (anything that is not winapi, win32, forms, mfc, wpf or some legacy xaml) then Visual Studio is just a limited experience at best, and a steaming pile of crap in most cases.
This goes for more software obviously, if you want to write C# but try to do that in Xcode, you're going to have a bad time. Same for when you need to write a Kubernetes controller in Go, that's going to suck really badly in VS or XC.
There are a few remaining systems that really benefit from unmanaged languages and strong OS-integrated tooling (the niches that were mentioned), but the mass development practises going on today are basically non-desktop and specifically non-windows-desktop. This means that a tool that was designed to be specifically for windows-desktop (or macOS-desktop for that matter) is unlikely to be optimised for anything else.
Windows Desktop as-is might not be a niche, but building local native desktop applications is. Even if you target Windows Desktop right now for a new application, it's likely that it's going to be some crappy CEF/Electron thing. And yes, that's crappy, but it also means you get to use much more of the knowledge/mindshare/community that is out there which is bigger than all desktops combined.
VSCode is still pretty sparse on the debugging side of things. I've tried to chase down heap corruption with it and the lack of data views, complex watch/breakpoints really limit it in that scenario.
CLion is getting there, it's not quite as good yet but was still much better than VSCode.
The C preprocessor is definitely ill-suited for metaprogramming, but it was never the C way, was it?
The traditional way to do any kind of meaningful metaprogramming in C is just a printf() to a .h or .c file which then is included to your build.
There are a lot of projects doing that. Bison is supposed to be used this way, other projects are doing build configuration like that - by emitting a header with a ton of #define’s, and there’s a ton of languages which use C as a compilation target - and you can see what they are doing and get inspiration from that.
In my opinion it’s an extremely powerful model, much better than anything you can do with the preprocessor.
If we are talking about such abstractions as Datatype99, this model is less convenient than native macros [1]. You have to write code in separate files, IDE support is lacking, sophisticating a build procedure, etc etc.
Native macros were never supposed to be used that way. If anything goes wrong, you still have to deal with that, and no IDE will save you from having to invoke your compiler with “preprocess-only” flag to see what you’re dealing with. Been there, done that, don’t want to do that ever again.
Compared to that, debugging generated code is a breeze.
Also, there’s no “third-party” generators - everything just lives in your own source tree. If I ever need to go meta, it’s just a printf away; I can even commit the generated files to my VCS and be able to see what had changed in them between commits in a simple and understandable diff.
Regarding the integration, I’ll take setting up an additional build phase (once) over having to debug C macros any day.
> Native macros were never supposed to be used that way. If anything goes wrong, you still have to deal with that, and no IDE will save you from having to invoke your compiler with “preprocess-only” flag to see what you’re dealing with. Been there, done that, don’t want to do that ever again.
~95% of errors from Datatype99 can be observed from the console, I hardly ever run my compiler with -E. What I mean by IDE support is that you invoke macros in the same files in which you write ordinary C code, you can't do that with printf. Imagine that you write your tagged unions (datatype(...)) inside separate files, it's clearly less convenient than embedded definitions.
> Regarding the integration, I’ll take setting up an additional build phase (once) over having to debug C macros any day.
I can't remember the time when I debugged already written and tested macros from Datatype99/Interface99, to be honest.
I agree. The reason I suggest it is to draw their communities attention to it, in the hopes their admins might be more willing to email you individually with a non boiler-plate answer or be more helpful to you.
An example to prove your point: Flipboard determined that our current rendering engine was too slow for their needs and implemented their own rendering engine on top of ours while retaining the rest of the browser infrastructure.
Yep. And as mentioned in the write-up, it brings lots of complications when it comes to accessibility. The same goes for SEO. It sounds like it was the right solution for them, but it isn't for everybody.
