Visual Studio Code 1.50 goes hard on extensions support, but tackling add-on bloat is becoming more onerous Microsoft has released version 1.50 of the world's most popular code editor, Visual Studio Code, with enhancements to core features, richer extension support, accessibility improvements, and not forgetting a build that runs on Raspberry Pi. The VS Code team delivers an update every month like clockwork, confusingly named by …
One day soon we will pass the Install Update event horizon, whereby actual computing work will become impossible due to not being able to install every available update before even newer versions of the first thing in the update list become available.
the fact that it uses Node.JS is bad enough, but when i played with it early on it was ALL 2D FLATTY FLATSO FLATASS (instead of 3D Skeuomorphic) and I _REALLY_ hate that. Nevermind the inherent slowness of JAVASCRIPT.
(this is why I stiil use DevStudio 2010 for C/C++ on Windows, which is happening less and less often these days anyway...)
From the art6icle: Is there anything that can disrupt it?
Yes. Micros~1 bloat. When a JAVASCRIPT EDITOR ultimately takes A MINUTE (or more) to load (give them some time, it'll happen), because of all of the bloat and extensions and 'did I mention bloat', performance goes out the window, and this is the problem Eclipse and InteliJ (which are actual JAVA, which is better) and other non-native-compiiled editors have had. That, and a potential "must have 16Gb of free RAM available or it won't even load" [do not doubt me, if unchecked, this is coming, we've seen this trend before].
I've DEFINITELY seen something like this with IntelliJ already, though not as bad as the 16Gb I suggested here. I think I managed to get IntelliJ to work acceptably with only 4G (or maybe 5G) for the VM that was running it by carefully tweeking its settings (unfortunately IntelliJ garbage collect memory MISmanagement is piggy, and Gradle made it worse). Later I allowed the VM to have 8G when I installed more RAM on my new workstation. And IntelliJ is compiled p-code Java, NOT JAVASCRIPT, which would be WORSE. So I have reason to make this future claim of hideous bloat and gluttonous memory hogging.
Why not just make an open source C/C++ native compile editor that uses a commonly accepted toolkit like Qt or GTK or wxWidgets so that it PERORMS WELL on embedded systems, and can also use X11 remotely to display on a local computer which is what I've been doing with pluma for YEARS now... and before that, gedit [until gedit's interface turned into SUCK, but thanks to Mate, pluma was forked from its earlier version and improved]. (Of course, I've been working on my own for several years but I still need to earn money to live on, too... which is why it's not finished yet)
"Why not just make an open source C/C++ native compile editor that uses a commonly accepted toolkit like Qt or GTK or wxWidgets so that it PERORMS WELL on embedded systems, ..."
Code::Blocks. As far as IDE's actually being executed on embedded systems, I've never seen the point as those are mostly proprietary traps (or just license stuff you have to deal with). I have no idea why you'd run Electron anything on a RPI, not unless you hate yourself or just think it's "cool".
VS Code will always be the "slow kid" wearing an Electron shirt, but it has its usefulness. Or maybe better put, commercially focused software receiving free work from the young OSS developers has its spoils :-) ie. a very decent Platform.io experience across Linux AND Win (I have to use both).
Back in ~2002, before the "Java == Bad" ideology, I actually liked IntelliJ for about 2 years. However, at some point in ~2012 I tried it again it was... too much. I still like Eclipse, but while I'm not a blind Java hater, I still don't want JRE anything :-/ (just like I don't want Electron anything). So, today I stick with Code::Blocks or Kate and yes, VS Code for my Arduino "stuff" (although Platform.io works well with Code::Blocks, but not Kate as far as I know).
Ever tried KDevelop (or QtCreator)? KDevelop has an AppImage download, which means that you can try out the newest version without having to install it.
They both have a lot of perks that you don't get to see on first sight. Both are more complete than Visual Studio Code, while being a lot faster and light-weight.
Why not just make an open source C/C++ native compile editor that uses a commonly accepted toolkit like Qt or GTK or wxWidgets so that it PERORMS WELL on embedded systems...
Beyond you, who runs an IDE on an embedded system? Everyone that I know does the work on a workstation, compiles the code with a cross-compiler, and then loads the image into the firmware. Unless of course your definition of embedded is different than mine.
A world which is not 1996
I remember stripping spaces out of my xhtml so they would load faster, and fretting about image sizes for days
That world has long gone. You may argue for better or worse, but it's irrlevant. It's gone and it is not coming back. Neither is the world where we use floppys, or worry about 200mb install files.
I've read some of the comments on here and I do agree with many of them. Visual Studio Code's 251MB install footprint is actually lightweight, considering that the full Visual Studio takes 6.01GB over 47,762 files and 9464 folders. Android Studio is worse. The IDE components take 1.59GB while the SDKs take up a whopping 126GB in 223,563 files and 28,057 folders. It likes to shove extensions down your throat based on the files that you are editing. I use a few based on the work that I do. One that I have found very useful is the vim extension. It has it's issues like everything else, but since I do a lot of work in a Unix environment using vi, it makes it easier to switch platforms between Unix and Windows.
VS Code: Beyond it's issues, it's a nice little editor that's lightweight, loads fast, and generally well behaved.
... it brings nothing to the table over simply using the command line tools in a terminal (since it simply uses gcc and gdb underneath) other than slightly quicker look up of definitions and values, which for me isn't enough to put up with its sluggish performance and over complicated GUI. I'm far more productive with 4 terminals open for search, edit, build, run & debug. But I guess I'm just old school.
Well try and begin describing them because neither of your posts bother. Do they provide any more debugging info or stepping ability over and above gdb? Any better compiler errors than provided by gcc? Is the editor any better than all the others available? No? Then I'm not interested. I want functionality, not pretty colours and cutesy icons.
Are you trying to tell me that running the compiler from the shell and picking up the error lines from there, then going to the editor and manually entering the line numbers to go to, is an advantage?
You sound like a troll. Starve. :-P
Perhaps give it a try sonny then you'll understand. What do you think we did before IDEs turned up?
And yes, it is an advantage because the shell has 101 other tools you can use too such as tracers, profilers, library decoders etc not that you'd probably know about any of them.
I notice you didn't answer the question btw.
Notepad++ is still used here when I don't need anything fancy save the usual syntax sugar and brace matching (e.g. C-family of code) clocks in at 9 MB total. Like boltar, the rest is done through various shells, tools, and the ever present makefile.
Not to say I don't use bigger hammers, I do. Updating Visual Studio 2019 as I type.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
