IMO the real loss in IDE tech is the speed that visual basic 6 gave you to make desktop guis.
Web and mobile development (which I have done all 3) are significantly slower than what you could do with VB6. It's really strange why we haven't gotten back to it.
VB6 was fantastic. The language was terrible, but the IDE was the best way to make GUIs that ever existed. The Windows 98 era was excellent for UX as well, with every element on the screen having an accelerator key, consistent menu guidelines, consistent visuals, keyboard shortcuts, etc.
VB6 worked because the environment was simple. GUIs are simple when you don't need to do any styling, do not require any special modifications and most importantly you don't need responsiveness. All of that, and you need a special environment and operating system to run the GUI. Web front-end are a completely different game in that regard.
Let's not forget Delphi and OptiPerl https://www.uptiv.com/free/optiperl/ Till date I have not seen any IDE that could reproduce its amazing box and line coding feature
>> but the IDE was the best way to make GUIs that ever existed
It was Lifted in spirit from NeXTstep's Interface Builder, so it was okay. But still a pale comparison.
P.S. If you are old enough, you will remember when $MSFT tried to steal Quicktime so its video products didn't suck. They got caught because they copied the machine code. Byte by byte. #howSad
I couldn't agree more, although I wouldn't be quite so hard on the language. It did have some strong points (for example, it was awesome for integrating with MS Office). To this day the GUI builder was the best I've seen. The current Mac stuff is more powerful, maybe, but the VB builder was way more intuitive and discoverable.
Back in those days, I (and many others) would use VB just to build the GUIs for C or C++ programs. It was that good.
Microsoft Access was way ahead, in my opinion. Especially that it came with a ready database, reports, etc.. and with VB6 you could practically do anything you want with the operating system. It's interesting we have thrown it all for something much more inferior.
That demo is partially faked - if you look at the "plan B" button, it doesn't actually make the UI show some newly changed data, it simply hides the entire window, and shows a different pre-made static window.
Even the "plan A" button code doesn't show the only interesting part of the code - how the UI is actually updated in response to the changed underlying data.
The IDEs I was making in VB6 in the 90s I'm making about twice as quick in Visual Studio 2022 in C# with WinForms.
In fact, quicker because I'm getting GPT to write any gnarly code I need -- like I just asked it if it was possible to add a tooltip to a ListBox and it churned out exactly the code I need, something I would have spent a bunch of time figuring out on my own.
In Delphi u didn’t need any code to add a tooltip to a component - just add it as a property in the inspector. U can do it in code if you want, but it’s easy to do since u see the available properties in the inspector.
I never used VS/C#, but can you drop a TDBGrid connected to a TDataset and then just resize autoloaded columns to your taste? Discussing tooltips on a listbox in RADs is like discussing colors of pencils in a hi-tech workshop.
>>Web and mobile development (which I have done all 3) are significantly slower
The above will probably take half a day in web development (assuming an experienced developer), so no, they aren't "totally wrong" at all.
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)?
There was also PowerBuilder and other "4GL" tools.
As an old fart, GUI toolkits and building tools are one of those categories of absolutely essential software that gets scrapped and rebuilt (not in a good way) for every platform.
Kind of like IDEs for new languages, to the point of the article. First comes the language and basic CLI tools, and then about ten years later you might have a mature IDE with full language-specific syntax coloring, autocomplete, visual debugging, variable watches, etc.
And these 4GL tools were doing this with BASIC variants (not compiled) atop maybe 200-300 Mhz processors and 16-64MB (not GB, MB) of RAM. It blows my mind that modern OSes have slowdown and stuttering when the amount of CPU, considering multicore, more pipelining, branch prediction, etc, is likely 100x stronger than the the CPUs back then.
The 4GL languages/tools were all closed source and that did not age well. PowerBuilder folded (probably killed by Visual Basic), and then Visual Basic was killed in one of Microsofts platform purges.
They also were tightly coupled with databases in a UI --> DB architecture. As server architectures exploded in complexity beyond that, the 4GL tools couldn't adapt, partly because they were leveraging so much power of SQL under the hood, and the various server and RPC/invocations never offered the same power and flexibility.
But I can hear you .. SQL over the wire? Like send SQL to a backend service so it can be intercepted and injected and all that? Yup, probably part of the problem. Thick clients and direct internal LAN communication is an implicit requirement.
I would really expect there to be some FOSS Python or JS insta-app-maker that's as easy as VB was, but for some reason nobody wants to work on such things.
Open source devs often don't like writing GUIs or documentation, which VB-like environments rely on very heavily.
Commercial devs meanwhile will work on those things, but generally want to host the resulting app on their own cloud for a monthly fee. That's lockin which is scary to people and so outside of platforms where there's no choice (e.g. Apple) they prefer to have a less productive dev environment but more vendor options.
30 years ago devs were much less sensitive to lockin concerns. Open source barely existed so the question was merely which vendor would you choose to get locked in to, not whether you'd do it at all. And fewer people had been burned by projects going off the rails or being abandoned. The VB/Delphi era ended when VB6 suffered execution-by-product-manager and Borland renamed itself to Inprise whilst generally losing the plot (wasting resources on Linux, etc).
Open source stuff tends to have much worse usability, but there are no product managers, no corporate strategies and in the unlikely even that the project decides to radically change direction it can always be forked and collectively maintained for a while. That concern outweighs developer experience.
Also the ecosystem is just way more fragmented these days. In the 90s everyone coded for Windows unless you were doing mainframe stuff, and on Windows there was C++, Delphi and VB. That was pretty much it and they could all interop due to Microsoft's investment in COM. These days you have JS, Python, Ruby, Java, Kotlin, Swift, C#, Rust, Go ... and they barely talk to each other.
Have a look at https://anvil.works -it's a drag and drop web app creator using python for front and backend. It's as close to Delphi for the modern age as I've come across.
They're trying to steer people away from end-user programming towards using more well-defined, tested, features. I find it patronizing, but, having seen some VBA, understand the reasoning.
Can't have user-programmable tools, because they could be used to ship (gasp!) malware, or let users (GASP!) work around policies of their employers' IT staff.
VBA can't really be removed due to the need to support legacy files (especially Excel). For more sophisticated stuff they expect you to use Office Developer Tools or similar now.
Windows Forms is pretty much the successor to VB6 and I think is still supported. Still nothing like it on Linux though, even though people say Linux is way better than Windows for software development :/
The subset of GUI software is much much smaller than the greater whole.
I do agree though that any GUI programming on Linux is a pain compared to Linux / Mac. However the proliferation of web based apps, even those running in electron shows how valuable a truely cross platform GUI framework that is easy to use would be.
Google is trying with flutter and dart but last time I used it I felt it was still being iterated on far too quickly, maybe a bit ( maybe even now ) it will be more friendly to use.
VB6 was primitive compared to what Delphi gave us. It had live design time data binding, visual form inheritance etc. VB and VC++ were primitive compared to that. VCL vs MFC? No contest. The API was powerful, fast, great to extend by inheritance, best in class layout management. There were about 8000 third party components at web sites like Delphi Super Page. Half of those were free, rest were affordably priced for commercial use.
Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience, while keeping Object Pascal (built with IDE experience in mind).
I still prefer the GUI building experience in Delphi 6/7 than anything that was produced since then. C#/Winforms is fine, it was designed by the same person - Anders Hejlsberg, but I wanted something native.
It's unbelievable that something modern like Flutter still fails to capture the design convenience of Delphi, from decades ago. Yes, the design markup is great, but I don't even want to look at it most of the time.
The later Swing/SWT editors never came close. Even Qt, which was inspired by it, never provided the component market experience of Delphi, and it was much more bloated in runtimes.
I fell in love with GUI design with Delphi, but otherwise hated it since.
> Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience
A very core aspect of LCL and how Lazarus works (and VCL/Delphi for that matter) is language features like metaclasses, RTTI, properties, etc which allow the framework to register classes, instantiate them at runtime and inspect the class definitions so that serialization/deserialization and IDE features like the object inspector will work. AFAIK neither Go nor Rust have this.
The only language off the top of my head that has it is C# (which isn't surprising considering both Delphi's dialect of Object Pascal and C# were designed by the same person).
Of course there can be language extensions like C++ Builder did for C++ but they'd need to maintain their own compiler (or fork).
Personally i get the impression that Visual Basic and Delphi's language features were added in tandem with the underlying framework (if not deciding first how the framework and IDE features will look like and then deciding on the language features to support those) whereas modern UI stuff are made with whatever the target language has in place.
Now try to make a layout with that form example that you could free form put anywhere in 2d space and have it flex properly as the window size changes beyond the defaults that html gives you and make the generic B2B SAAS dashboard like Segment, RevenueCat, Mixpanel, Datadog, Sentry, etc. I bet you could make a VB6 / Pascal equivalent much faster than you would be able to with a mobile or web app, especially if they were updated with a decent graph widget set.
Also your two examples are drawing canvas examples, thats a pretty different target that delphi / vb6 have with their GUI toolkits.
Flash and Actionscript did this for the web but then Apple killed Flash.
Maybe in the era of LLM-assisted webdev tools (like teleporthq.io or MS Sketch2Code etc) the LLM will help sidestep API moats and help bring back such low-code IDEs. Or it could backfire and bring about API moats with non-human-accessible APIs (obfuscated binary only).
Adobe claimed that they could get Flash running on the first iPhone if Apple let them.
When Flash finally did come to mobile via Android in 2010, it required 1GB of RAM and a 1Ghz CPU and it still ran badly.
The first iPhone had a 400Mhz CPU and 128MB of RAM. It could barely run Safari. Were you around when the only way that Safari could keep up with your scrolling was by having a checkerboard pattern while waiting on the screen to be redrawn?
I dunno, I worked with Qt5 and Qt6 recently and creating a UI felt pretty fast and smooth to me (Much more so than the last time I did frontend web work anyway)
That said, I've never used VB6 so maybe I'm missing something...
No, Delphi came out years after Visual Basic. There was an earlier Turbo Pascal for Windows, but it didn't have visual design features as far as I remember.
I loved TurboPascal.
I agree with everything the post argues.
I would like to expand a bit on it being before the Internet was a huge thing.
The manuals that came with TurboPascal were nearly excellent.
It included most of what you would need to get started.
When you didn't quite understand something, you had to spend time to
figure it out and how to do it well.
This could be time consuming, but afterwards you gained important knowledge.
Then there were other books to get, there were "coding" magazines,
though at the moment I cant remember any TurboPascal specific ones.
and if you were lucky you knew one or two other people who were into
coding and you could share problems, solutions, hints and tips. and warez.
There were also a lot of BBSs out there.
Where you could ask questions, help others, etc.
These days most people if they face a problem, Google it (maybe now ChatGPT it) find someone posted a solution, cut and paste the crappy code, crosses fingers that it works and off you go.
(or pull down libraries without having any idea what in the world it actually does)
At the same time things have gotten a lot more complex .
In my TurboPascal days I knew most of the stack.
The programming language, the operating system, assembler,
a lot of how the CPU worked.
These days understanding javascript, understanding the runtime / compiler etc,
before you even get close to the underlying OS, and certainly not down into assembler amd CPU
I'm not sure whether the issue is stack complexity / depth, but there is definitely something in the culture where it's common for docs and how-tos and Q/A to tell you what to do, the steps/commands/etc, but to do little to help you build any kind of relevant domain model.
This isn't exactly new, there's always been documentation like this, but I think the proportions have changed dramatically since even the early 2000s.
One of my vaguely defined theories is that as valuable as automation is, the culture of automation / process has started to diffuse and act as an influence on how we think, in steps & commands rather than models.
Possible that we've always been steps-results / input-output beings, but I wonder.
I recently created some documentation for a process at work where I explained the 'why' for most of the steps and commands. Not in great detail, but just a bit of detail. I thought that it was good as a step-by-step recipe, while also giving context that could help someone in the event that something didn't go according to plan.
I was asked to remove much of the context that I provided, so as not to confuse the reader, and to make it as direct as possible. This is documentation intended for experienced, technical professionals. I think that the revised documentation is less helpful.
Everyone wants a quick fix these days, in all parts of their life.
How to do X in [an hour, a day,one week of lunches, 30 days.]
Heal yourself from X in [an hour, a day, one week of lunches, 30 days. ]
Eat/Dont eat this get slim in [ one week of lunches, 30 days, 60 days]
A long time ago I studied martial arts (Karate).
Our structure went up to the master in Japan.
Once you got past the orange belt, the only way to progress
was when the master was visiting.
the master also decreed that you had to have a belt for min 1 years,
in brown 2 years. in black 4 years before you could try to graduate.
He said people needed to grow into their skills and mature.
I haven't thought much about that until a few years ago a colleague told
me her daughter had just gotten her first black belt.
Knowing her child was no more than 12 that seemed odd,
but she had studied hard for almost 2 years.
That seemed like some form of fast-food martial arts.
By pure coincidence I met the son of my previous master at a train .
I knew him but the last time I saw him he was still a kid.
He was Japanese as well but he spoke excellent English.
Something his father had no interest in.
He had taken over from his father and was now the master.
We talked a bit his dad, the clubs.
I mentioned this rapid progression that my coworker's daughter had done.
He leaned back and laughed a little.
Yes, too many cookbooks, "with solutions and examples", and no one writes good reference manuals any more.
I kind of get it. I think about a problem, and I am solution focused. Furthermore, I want to learn what I need to implement the solution, and usually don't pay attention to other features that are not directly related to my problem.
However, by giving me a cookbook, the documentators are doing me a disservice in two ways: first, they are greatly limiting the amount of solutions I can use. If my problem is not something they already imagined, I need to find another cookbook or read their source code to find out how to solve it.
And second: they are taking away from me the process of learning about the different parts of the system and how to integrate them into a solution by myself.
And the gotchas are endless. I am using FastAPI and the amount of things I have no idea how they work underneath, until something fails, is mind wrecking.
I wish there was some real reference manual of it, not just the autogenerated function signatures and the most minimally useful documentation I have ever seen. So many things make no sense, and I have to second guess the FastAPI designers all the time.
> there is definitely something in the culture where it's common for docs and how-tos and Q/A to tell you what to do, the steps/commands/etc, but to do little to help you build any kind of relevant domain model.
So very true and this is actually my biggest complaint with MSDN nowadays. It's so difficult to built a mental model of what's actually going on, which makes the documentatino difficult if your needs aren't exactly what the documentation is describing.
I don't know when this phenomenon started but it drives me batty.
Manuals in the era were in general pretty good comparing to today’s open source software standard. Microsoft C++ has about 6-7 dictionary sized books as the manual.
Love that era. I’d definitely pay more if say Jetbrain has these kinds of manuals. But it doesn’t make sense nowadays to have printed manuals, not only because of the cost, but because nowadays people don’t need to read books about language specifications.
For a while I was a contractor at a hush hush place.
We had extremely limited internet access and even stronger rules not to use it.
No cellphones, no Wi-Fi, no BYOD.
It was like going back to the good old days with books.
We were given the opportunity to order books.
I adapted the best of our team but probably only because I am old.
We had one good old fashioned corded phone, which was for internal
calls only. It was not hooked up to anything "outside".
We were given a number that our nearest could call in on.
The number should be connected to some semi anonymous
front desk somewhere.
It was to be used (only) in an emergency (they emphasized that)
The routine would be that a member security detail would come
to notify the relevant person, escort that person to a room
with a phone, that the front desk could route the call to.
Someone might or might not be listening in.
As far as I know nobody tried it.
I dont know if the routine is still the same now.
I would guess that younger developers would have a much harder time
adjusting now than back then.
The article covers some good points, but misses a few extra things that the Turbo Pascal 7.0 IDE included that made it a true powerhouse:
- A full OOP tree to determine parents/traits of descendant objects
- The ability to edit, assemble, and trace through both inline and external assembler code
- A registers window that showed all registers and flags at any stage of runtime
...all while able to run on the first 4.77 MHz 8088 IBM PC, which was long in the tooth by the time TP 7.0 came out. (The OOP tree required a 286 as they only added it to the protected mode IDE.) This made the TP 7.0 IDE a complete development and debugging environment for assembler as well as Pascal.
I still use it on that hardware for hobby projects, and while I have to wait 60-120 seconds for a compile, it's still more convenient for me than cross-compiling on Windows and then copying the code over.
It's not how well the bear dances, but that the bear dances at all. That said, EMS and a solid-state hard drived do help a little.
> there are a few things that VSCode doesn’t give us.
> The first is that a TUI IDE is excellent for work on remote machines—even better than VSCode. You can SSH into any machine with ease and launch the IDE. Combine it with tmux and you get “full” multitasking.
I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
Because of VS Code's web roots, it can easily run its frontend on your own local computer while running its backend somewhere else. This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server. The operations that do have to be executed remotely, like saving a file for example, are properly asynchronous and don't interrupt your workflow. Everything is just far snappier, even if you're working from home, through a VPN, on barely working WiFi and an ADSL line.
As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
The resource consumption on the client doesn't bother me one bit. Any minimally decent laptop can put up with that load, on battery power, for hours.
I would agree with “whatever it takes to make the server install leaner, more portable, etc” just without sacrificing many features.
If the server side doesn't run on FreeBSD that's really too bad. If Microsoft makes it hard to improve by not making those bits open source, that's very unfortunate.
VS Code remote in some cases is better than local.
As the remote can be a docker container, so when I have to do some experiment, I create a container takes 5 min to setup. I than can play around, test dozen packages and configs, once I am comfortable commit last version.
If I want to do some quick testing on project by different team, again a local container is setup in 2-10 mins. Once done delete the container and my local system isn't messed up.
Last is obvious use case if you want to test anything on reasonable large data or GPUs. Create a cloud server, get data run your code, tests. Push data to S3 and done.
It's similar in outcome (doing "stuff" remotely), but not the same architecturally.
VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').
With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.
In the spirit of what the person you are replying to wrote, you really weren't doing the same thing 30 years ago, because X Windows doesn't really have the capabilities vscode has for remote work. X Windows approach is very primitive compared to what vscode does.
> I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
> As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
> I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
Not sure about other languages, but when I use VS Code to develop Rust remotely, it prompts me to install the rust-analyzer extension (which is my preferred LSP server for Rust) to a remote whenever I'm opening a project for the first time. VS Code is able to distinguish between extensions that need to be installed on the same machine as the code (like the LSP server) and extensions that are just making changes to the local UI.
> Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
I use an extension for vim keybindings in VS Code. When connecting to a remote host, the vim plugin still works fine, itand doesn't prompt me to install anything on the remote side, since the changes are synced to the remote host at a much higher level than that (i.e. locally mapping "dd" to "delete this line from this file" and sending that to the remote rather than sending the remote the keystrokes "dd" and having the remote determine how to interpret it).
My understanding follows (I don’t use it but I’ve noticed the processes running on other people’s machines). Corrections welcome.
It’s split into a client (web frontend) and server that’s doing all the work. The server can be run anywhere but it’s effectively a bunch of stuff installed in a docker container. When you start an instance for a project, it creates a container for that instance with all the code folders etc bound in. LSPs are running in that container too.
It’s possible to use your own image as a base (you might have custom deps that make installing the requirements for an LSP hard, for example).
The trick they use here is that there’s some base container/volume that has most of the server stuff downloaded and rest to go. Whether you start a normal instance or from a custom image they do it the same way by just mounting this shared volume and installing what they need to bootstrap the server.
It also appears they create a frontend window per server process too. So the master client process starts, you select a project folder, they create a new server container and a new client window connected to it. The frontend client is local while each server can be anywhere (obviously you could run the client with X if you wanted to further muddy that).
I use that all the time in my hobby tinkering pseudo cloud server on a odroid SBC. It feels like I'm literally on that specific computer directly. Plugins like docker work as well
I've been wanting to try something like that with neovim's remote features, but haven't found the time. Has someone attempted this? If so, how successful was it?
I've always been a big user of powerful laptops because I do like the mobility (allows me to work/browse stuff outside my home office) and I dread the pains of properly synching my files across a laptop and desktop (not only documents/projects, but also configs and whatnot).
Using the editor on the server from a remote connection is silly. However VSCode is not unique. On my local Emacs I use ssh via tramp [0] to browse files on the server and then edit localy. HOWEVER I also have physical access to my server. Emacs then gives me the added benefit of being able to run in terminal on the physical server without any window manager installed.
> Using the editor on the server from a remote connection is silly.
In my experience, this is the best way to do remote work. The alternative is to either not work with remote resources (data, hardware, etc), work locally and sync changes to remote, or work locally with a remote mounted file system (unless you need remote hardware).
For the parent, they needed GPU access, so they had to run remotely for hardware access.
I normally need particular data that is too big to move locally, so I like to work remotely for that reason. I could remotely mount drives via an SSH Fuse mount, however the IO speed for this method can quickly become a problem. For me, it is a much better experience to either use a remote web editor (rstudio server), VSCode remotely (which is a remote web editor over ssh), or vim. With web based remote editors, you still draw the screen locally, but get updates from remote. And more importantly, compiling and building takes place remotely.
I find this method much better than either pure remote access (VNC/RDC/X11) or local-only editing with syncing code and/or data. But it very much depends on your work. When I don’t need to work with remote data, a locally managed Docker devcontainer provides a much better development experience.
I worked at a place that had a half built distributed system that we still needed to use (many bidders buying Ad space from a API based market). one great thing with tramp is that you can tramp into multiple systems simultaneously. So you are editing say files from 5 different systems (tweaking the yaml or whatever) at the same time. You could then start eshells on each of those systems at the same time. It made it really easy to adjust the settings and restart multiple apps really quickly (big screen, 5 files on top, 5 shells on bottom). I always get a kick out of people saying "you use that! you need to switch to editor X it has feature Y!" And me thinking yeah, that feature has been in emacs since before you were born. it is getting a bit crufty in its age though. Its main attraction is for people who like LISP. There a project called lem (IIRC) that is rewriting it in much higher performance Common Lisp.
This ability also proves useful when trying to do complex package management in an isolated manner with ROS; I ultimately used a remote vs code shell running off the robots OS to just have my ide recognize the many local and built dependencies that requires a full ROS setup.
People still forget Eclipse when it comes to a full-blown yet not bloated IDE. That thing consumes less than a bare bones VSCode install while running 5x the tools. It can handle everything from code to git to CI/CD and remote development since 2013.
I'm using it for 20 years and I think it's the unsung hero of the IDE world.
This article doesn't mention it either as a modern GUI IDE.
There’s a reason people don’t talk much about Eclipse these days and it’s because it was a pain to maintain back when it really should have shone.
I really wanted to like Eclipse but gave up on it a decade ago because it required constant management from release to release. I remember one job I had where I didn’t need an IDE all that often and I would spend nearly as much time configuring Eclipse again upon the next time I came to use it, as I was spending time writing code in it.
I’m sure it’s improved leaps and bounds in that time - 10 years is a heck of a long time in any industry, let alone IT. But I do know I wasn’t the only one who got frustrated with it. So myself and others switched to other solutions and never looked back.
> I remember one job I had where I didn’t need an IDE all that often and I would spend nearly as much time configuring Eclipse again upon the next time I came to use it, as I was spending time writing code in it.
So basically the same as setting up and configuring a development environment today, except that nowadays it's a lot more centered around the command line and involves a bunch of disparate, half-documented packages/tools from GitHub (and that also inexplicably require 10 to 1000 times more space and clock cycles).
I used to like Eclipse but honestly it was and still is a hog. At the time i used it in the late 2000s it was basically the best IDE for C++, having features that Visual C++ users either did not have or needed to pay extra for plugin to get. I used it at work then when everyone else used Visual C++.
However at home i had a computer i bought late 2003 (which was a high end PC at the time but still) and the program was so heavy i remember despite running it under a lightweight environment (just X with Window Maker) i had to choose between Firefox and Eclipse because otherwise things would crawl due to the excessive memory use both programs made :-P.
Eventually i switched to other IDEs and forgot about Eclipse. But i did try it recently again and while obviously doesn't feel as heavyweight as it did back then (i'm running it on a 8 core machine with 32GB of RAM so it better be), it still feels sluggish and startup time is still quite slow.
Also TBH i never liked the idea behind workspaces.
These days i don't write C++ much but when i do i use either QtCreator or Kate with the Clangd LSP (which i also use for C).
I think 9 seconds startup time with 1GB of memory use is pretty acceptable for an IDE at the size of Eclipse (just timed).
Considering I'm not closing it down for whole day when I'm using it, waiting for ~10 seconds in the morning is not that bad.
In 2003, Eclipse was at its infancy and was an absolute hog, I agree on that front.
Actually you are not expected to have "n" workspaces. Maybe a couple (personal and office) at most. Project relationships and grouping is handled via "referenced projects".
Kate is an awesome code-aware text editor. I generally write small Go programs with that, but if something gonna be a proper project, it's always developed on Eclipse.
It wasn’t “a hog” it was the hog. I don’t know where OP gets the idea that it was svelte. IntelliJ is considered a pig and a half in most eras but at the time, for most if not quite all projects, Eclipse had a worse memory footprint, for less functionality.
Also the UX was mediocre at best and infuriating at worst. Practically every interaction worth performing in that editor took at least one more click or keystroke than IntelliJ, and I would rank IntelliJ as merely good, but not amazing with input economy.
For about five years, my daily start of the day ritual was starting eclipse, going to a 10 minute standup, and coming back two minutes before it stopped loading. To be fair, it's probably better now, and I stopped doing Java work in 2014.
what I dont understand about java is why doesn't it just take what it needs? If I commanded eclipse to open, that's it. Open an editor, maybe 2-3 recent files, and let me move the cursor around. If IntelliJ isn't ready yet, so be it, but dont slow my UX down because it's running a bunch of services I didn't ask for. If I hit the IntelliJ autocomplete then fine, I'll wait if it's not ready, but until then, the editor frames should be just as snappy as notepad. Java doesn't put the user first!
Interesting. I hate Eclipse with a passion, I find the ergonomics so horrendous, and back in the days it was a hog. Maybe on today's hardware it's leaner than webkit based vscode. But the last time I tried to use git with it .. it made things 10x harder than the CLI. It was so bad that I developped RSI in 24h (and I'm a daily emacs user)
It’s possible that Eclipse has had a “Firefox moment” where someone carved it down to a lighter core, but I’ve no reason to check.
Seconded on the ergonomics. They were a joke. Longest inputs of any IDE I’ve ever used. If your sequences are longer than vim you need to get your head examined.
Sorry, but "not bloated" really doesn't enter my mind when I think of Eclipse. The few times I used it for Java programming, it took forever to start up, and the UI was laggy as hell during regular use. Granted, that was about 10 years ago, but on a (at the time) beefy Windows PC.
It was, for C++, for a couple of years, 12-13 years ago. It's neither laggy nor slow for the last 8-9 years. I've written my Ph.D. thesis on it, on C++, which was a sizeable high performance code.
It never crashed, allowed me to work remotely if required, integrated with Valgrind, allowed me to do all my tests, target many configurations at once, without shutting it down even once.
Currently it has a great indexer (which is actually an indexer + LSP + static analyzer and more), LSP support if you wish, and tons of features.
It gets a stable release every three months, comes with its own optimized JRE if you don't want to install one on your system, etc.
Plus, it has configuration snapshots, reproducible configurability, configuration sync and one click config import for migrating/transforming other installs.
My experience with Eclipse, about 10 to 15 years ago, was the exact opposite. It was incredibly bloated. With some combination of plugins installed, it became unusable. At a previous company, we were using some sort of Scala plugin, and Eclipse couldn't even keep up with my typing! I moved on to IntelliJ around that time.
All of the JetBrains users sitting around comparing notes, trying to figure out what was wrong with our coworkers that they thought eclipse was worth using, let alone defending.
JetBrains has plenty of problems, which they seem to want to address but I fear Fleet won’t fix, and I lament but understand people wanting something lighter these days, but eclipse isn’t even in that conversation.
I (author) wouldn’t say I “forgot” about it. I was there when Eclipse became a thing, and my memories are all pretty grim. Difficult to use, slow, very resource hungry… so I never really paid much attention once I finished school. It probably is better now as others are saying, but I don’t know nor care at this point to be honest.
I have good memories of Eclipse, from back when I was doing Java. I remember at the time it seemed everyone dissed it, much as it feels like everyone disses Jira now and for the last decade, but I liked it.
I think you are mistaken, Eclipse takes up 3 times the ram VSCode does...I can use VSCode using only 6gig ram even with big projects with native code such as kotlin, java, c, swift, etc..Eclipse will not run on 6 gig ram neither will jetbrains or android studio.
I still love Eclipse, and you can pry it from my cold, dead hands.
The last couple of years, however, it feels like Eclipse is actively getting worse. And I don't mean that it's lacking features. I mean that every new release seems to break something else.
I tried reporting some bugs, but that required signing some kind of soul-selling agreement with the Eclipse Foundation or some other nonsense.
I then tried fixing those bugs, but there is no up to date documentation on how to build the IDE from the myriad of repositories and modules. So I gave up.
VSCode is really a text editor-in-IDE-clothing. Also, it's an Electron app and those are notoriously resource heavy.
~20 years ago I became an early IntelliJ user. From version 3 maybe? It's hard to recall. I've never looked back.
But I did try Eclipse and... I never got the appeal. For one, the whole "perspectives" thing never gelled with me. I don't want my UI completely changing because now I'm debugging. This is really part of a larger discussion about modal editors (eg vim vs emacs). A lot of people, myself included, do not like modal editors.
But the big issue for Eclipse always was plugins. The term "plugin hell" has been associated with Eclipse for as long as I can recall. Even back in the Subversion days I seem to recall there were 2 major plugins (Subclipse? and another?) that did this and neither was "complete" or fully working.
To me, IntelliJ was just substantially better from day one and I never had to mess around with plugins. I don't like debugging and maintaining my editor, which is a big reason why I never got big into vim or eclipse. I feel like some people enjoy this tinkering and completely underestimate how much time they spend on this.
For me, perspectives are perfect, because it provides me a perfect set of tools for everything I do at that moment. It's probably a personal choice, so I agree and respect your PoV.
The plugin conflicts were way more common in the olden days, that's true, however, I used subclipse during my Master's and it was not incomplete as my memory serves. It allowed me to do the all wizardry Subversion and a managed Redmine installation Assembla had to offer back in the day.
It's much better today, and you can work without changing perspectives if you prefer, so you might give it another shot. No pressure though. :)
Trivia: VSCode Java LSP is an headless Eclipse instance.
I’ve been using vscode for a few years now and while i find its search amazing, it doesn’t do much more for me. Its syntax highlighting is good, but the auto complete recommendations have been driving me insane recently.
Writing rails api with a nextjs ui, anyone got any suggestions on alternative paths i should take?
This is kind of my problem with it. I'll use VSCode for typescript but I avoid it if there are other alternatives. The entire model of VSCode just doesn't jive with me.
Ha. I mostly used Eclipse in college. I learned how to compile programs from the Command Prompt (Windows user back then) primarily to avoid Eclipse LOL. It was dog slow and somewhat difficult to navigate
There does seem to be a lot of hate for eclipse. The complaint I always hear is that it is a pain to use. Personally I’ve always liked it, even though I’ve used the other popular IDEs.
A blast from the past there. I used Eclipse for Java in its infancy while I was at university and thought it was decent enough compared to whatever version on emacs would have been on whatever version of Solaris was on my CS department servers.
A couple of years later I started an internship at a bank and spent ~3 hours trying to get a project building before someone introduced me to IntelliJ, which I still use every day almost 20 years later!
I'm shocked to hear you describe it as "not bloated". Eclipse took many seconds to start up, responded slowly to typing, and used huge amounts of memory. It was by far the slowest of any application I had used. I used it when I had to, but never got comfortable with it because it was just way too slow.
I should fire it up, I haven't tried it in a while. It was the only thing I could use that seem to accurately (more or less) index large projects that you, uh, had some issues compiling and just want to navigate around and look through the code. now I mostly just use rg for big projects, inside of neovim
Eclips also had (have?) The very interesting mylyn plug-in which narrows down the code to the context your working within. Think collapsing everything in eg the project tree and also functions within files.
This context is built up based on what part of the code you work on.
Honestly, I feel like the primary reason why IntelliJ "won" over Eclipse and Netbeans was that it was first to market with a decent-looking dark mode. Back when Eclipse and Netbeans were as stark white as Windows Notepad... and caught with their pants down as developers abruptly decided en masse that white backgrounds were over, and every app needed to be dark mode first.
Hell, Eclipse STILL doesn't really have a nice dark mode. The actual editor view looks okay, but the dark mode feels very bolted-on to the surrounding UI.
I think this is the primary reason why VSCode is eating the world today. People will talk about the plugin ecosystem and all these other community inertia advantages. However, VSCode was exploding in popularity BEFORE that plugin ecosystem was in place! If we're really honest with ourselves, we flocked to because it was even more gorgeous looking than Sublime Edit, and without the nag modal to pay someone 70-something dollars.
JetBrains “won” because of code inspection tools and code completion that was light years ahead of Eclipse and Netbeans. I remember in my Java days I used to be able to do in a keystroke what my Eclipse friends did in a dozen dialogs.
For me, the closest modern successors to the Borland suite are Visual Studio (not VSCode) and the Jetbrains IDEs. The feel like they're the only one with a holistic, batteries included, design that actually focuses on debuggability.
I actually feel that the terminal-based focus of modern FAANG-style development actually hindered proper tool development, but I was never able to explain it to anyone that hasn't used Borland C++ or Borland Pascal in the past, except maybe to game developers on Visual Studio.
C++ Builder versus Visual C++ for RAD GUI development.
I never understood why Redmond folks have so hard time thinking of a VB like experience for C++ tooling, like Borland has managed to achieve.
The two attempts at it (C++ in .NET), and C++/CX, always suffered push back from internal teams, including sabotage like C++/WinRT (nowadays in maintainance as they are having fun in Rust/WinRT).
The argument for language extensions, a tired one, doesn't really make sense, as they were Windows only technologies, all compilers have extensions anyway, and WinDev doesn't have any issues coming with extensions all the time for dealing with COM.
Or the beauty of OWL/VCL versus the lowlevel from MFC.
DevDiv vs WinDev. The Windows group maintains the C++ compiler. So you get the resource editor for dialog templates and that’s about it. And that actually got worse from Visual Studio .NET onwards, my guess is that it got took over by the DevDiv people when they unified the IDEs.
I guess it's caused by the "brogrammer" culture of Silicon Valley, where you would get hazed if you dared using a GUI-based tool.
Also, being more focused on open-sourcing their tools (because other companies do not open source them, therefore being un-cool), which begets a "simpler" and "engineeristic" approach to UX, which do not need UI experts and designers.
Lots of companies end up with their own internal tooling. They have their own build systems, packaging systems, release systems, version control, programming languages, configuration languages, everything.
Some even have their own editors.
There is a lot of value in picking a transferrable editor and using that. From that point it becomes "what is the best editor that will _always_ be available". Emacs/Vim fit that.
Then the muscle memory can begin to grow, and there is one less bit of friction in starting a new job.
One of the best pieces of advice I received was "pick an editor and go deep".
Except maybe Apple, all the others are service-oriented companies. They run heterogenous pieces of code on their servers and their ideology is “move fast and break things”. It’s a hipster culture that reinforced the use of 1980s “video terminal” editors and CLI tooling because they were supposedly more flexible for their workflows.
I loved Turbo Pascal, but to me the high point of Borland's tooling was Delphi (1995). I don't want to sound like old man yells at cloud, but every time someone says that building GUIs with Electron is so easy compared to native apps, I just wished they experienced Delphi in its prime.
There are some very short/simple demos on YouTube:
> but every time someone says that building GUIs with Electron is so easy compared to native apps, I just wished they experienced Delphi in its prime.
Every time someone says that, I mention Lazarus. I stll get a thrill out of using it (one of my github projects is a C library, and the GUI app is in Lazarus, which calls into the API to do everything).
The problem I find with Lazarus is that it seems to be slowly dying; yes, they still work on it, but feature-wise they are very behind what can be done with HTML+CSS and a handful of js utility functions.
A wealthy benefactor could very quickly get Lazarus to the point of doing all the eye-candy extras that HTML+CSS let you do (animated elements, for example).
I will happily fill an hour with trash talking Microsoft, but getting the father of Delphi on board is one of the shrewdest things they’ve managed. I wish he’d found a different project to sink his teeth into though.
I still miss the simplicity and power of the Lightspeed/THINK IDEs for Pascal and C.
For me Metrowerks was a big step back in terms of complexity, speed and affordances.
The thing that I loved about MPW was MPW Shell and Commando, brilliant if you compare it to the state of the UNIX art at the time, probably tcsh, and still to this day feeling just a bit like the future.
At least the programs in the screenshot have actually useful and visible scrollbars. Seriously, scrollbars are super useful and should never be hidden, they both provide information you want to see and actions you want to do, why is everything trying to make them as subtle as possible today, even most Linux UI's which I'd expect are normally made more for usefulness than "design trends"?
GitHub's Android app doesn't even show scroll bars. And no scroll grab or snapback in apps even when there is a scroll bar. Am I the only person who scrolls back to check something and wants to quickly return to where I was in a document? Even if just FF on Android had this I would be happy.
On desktop we can drag scrollbars but I can't imagine what it's like to use modern 4-8px action area scroll bars if you have fine motor control challenges.
I just don't understand how we got to this point. Do people not use the apps they write?
This must be a bug though. If you unfold hidden comments, you jumpt to the BOTTOM, where you just WERE, rather than the top. So you scroll up, with no scrollbar, frantically, because you don't know how far you have to go. Until you reach the top - and you drag down ONE MORE TIME, because you're scrolling frantically, so the whole thread reloads, and everything is folded again, and you're back where you started.
On Linux this depends on your theme really, all the themes i use have scrollbars - e.g. here is an example with Gtk3 (which IIRC introduced the "autohiding scrollbars" to Linux desktop)[0]. It is "cdetheme-solaris" which i think is from [1]. I might have modified it a bit though. Though normally i use Gtk2 apps with a modified "cleanlooks" theme (a screenshot from Lazarus[2] i made a couple of days ago shows it - including the scrollbars :-P).
Even if VSCode/other IDE had features that blew Neovim out of the water, I don’t think I’d move over. The customizability, modal aspect, and open-source-ness are huge for me. I can create macros on the fly for repetitive tasks, can navigate without ever having to stall my train of thought to touch my mouse, and customize every single key binding and the code that it runs. I can create custom commands to do every single thing I’ve ever conceived of wanting to do. I can upstream bug fixes and see those others have suggested that haven’t been up streamed yet. I will concede that for some, maybe this is too much work to set up “just a text editor”, but I enjoy it, and I spend most of my day editing or viewing text, so to me, it’s worth it.
If there is one thing I’ve learned in my years of software engineering, it’s that everyone prefers different workflows. Let people build their own, however they want, with whatever tools they want, and they will be happier for it.
Almost everything you wrote is available for any modern IDE, and modern IDEs, thankfully, don't assume that your code is text. So they give all the things you mentioned and superior tools to work with code out of the box: anything from refactoring to code analysis to several types of semantic search to...
Corect me if I'm wrong, but you can't define macros in a couple key strokes or contribute to development of any modern IDE.
Nor they were designed to be hackable or customizable. If you open one of the setting sections in VS-Code you are presented with giant, over-engineered control panel with myriad of options you can toggle.
Where Vim has a blank canvas you splash with couple dozen lines of code to make it unique and personal. It's almost like you aren't using just vim, but your own hand-made editor built on a great minimal base, that is Vim.
I am easily distracted (as in, ADHD-like), I enjoy very sparse work spaces in general. Tools with lots of icons, windows, and other widgets are very uncomfortable to me. I prefer typing commands, I believe a well written command language and a good search function are more comfortable. I will go to great lengths to avoid some tools if it means avoiding a clickodrome : for example, when coding for STM32 devices, I prefer bare metal GCC + makefile over STMCube.
To each his own tho, it's nice to have different tools for different peoples.
The two most indispensable programs for me are "midnight manager" for Linux/OSX and the like, and "Far Manager" on Windows (and mc there too under wsl2).
I'm lost with Far Manager at work. I've stopped using Explorer long time ago (and use it only to verify some reported workflow from other users, or some obscure thing not possible in Far Manager).
Other tools: tig (pager), emacs, mg (mini-emacs) - I wish that was available on Windows too without needing msys2/cygwin, and few others.
Back in the DOS days - it was Norton/Volkov Commander, PC Tools, but also Turbo/Borland Pascal 3, 4, 5; the most awesome E3 editor (from this series - https://en.wikipedia.org/wiki/E_(PC_DOS) ) - and many more
30 years ago, THINK C for the mac was already nearing discontinuation. It was a great compiler plus plus graphical IDE with debugger for its time. Hard to find info about it, but this site has some screenshots of the various versions:
Yes! I absolutely lived in Think C for many years. You’re right though, it was on the way out by then, supplanted by CodeWarrior and MPW, which were both really good too.
Visual Studio and XCode are the closest experiences to “first-class IDEs”, reminiscent of the Borland stuff from the early 1990s. They offer tight integration with the native toolchains and a set of menus that mostly make sense. Environments like VSCode or Emacs are a generic platform for text editing and file manipulation, a lowest common denominator for a variety of languages, workflows and tastes.
How odd to find a mistake in 30-year-old Turbo C++ man pages from a screenshot. printf and vprintf send send formatted output to stdout of course, not stdin.
Language server protocol has really improved things. I use it with neovim. Makes it straightforward to get IDE features in vim for a variety of languages & allows code analysis part to compete. With Go I'm mixing golangci & gopls. In Rust there was a transition from rls to rust-analyzer. & this effort is able to be shared between vim/vscode/emacs/etc so once someone makes a good lsp implementation it doesn't need to be ported everywhere
I was expecting the author to mention Smalltalk because I distinctly remember people praising Smalltalk for its IDE but I think the IDE I was thinking of is from the late 90s or early 00s.
> I think the IDE I was thinking of is from the late 90s or early 00s.
Smalltalk's from the 70s and 80s, and almost certainly had what you're thinking about given it's where both Microsoft and Apple got their foundational ideas (restricted to significantly less powerful hardware), and later unrelated smalltalks retained a lot of now quirky considerations and behaviours. Self inherited a lot of those and is from the late 80s.
So yes, I was also expecting the author to talk about Smalltalk.
If you actually look at Xerox’s hardware, it’s quite a stretch to call Lisa or Macintosh “less powerful.” It’s kind of amazing what Xerox was able to accomplish on such underpowered systems; they did it largely by having multitasking microcode to handle performance-sensitive I/O, and implementing BitBlt there too.
I suspect there are quite a few more niche languages/interfaces that the author didn’t consider when it comes to GUI IDEs. I thought of EiffelStudio immediately, myself, having worked with a group that used it in a past life.
I don't think SmallTalk ever had a TUI. Even the very early versions on the Xerox machines used a GUI, and that GUI persisted even when it was all ported to Solaris.
Oberon was this weird mix where you had a proper GUI on thr screen but it would basically only show text. You could run commands by selecting text from inside any arbitrary window. The plan9 OS and Acme editor have kept this workflow.
The title of the article doesn't mention TUIs (or UIs at all) but I was thinking of a GUI. Specifically it seems I was likely thinking of Pharo (which is '00s not '90s so off by a decade).
Vim is the only tool I've been able to use at every place I've ever worked at, from intern to staff engineer in three FAANG companies. I've watched tool teams spend months integrating the latest GUI editor, only for it to get killed by corporate acquisitions and replaced with N+1 that offers an almost identical feature set.
Meanwhile there's always a community of vim and emacs users who build all the internal integrations by themselves. Vim and Emacs aren't editors, they're platforms and communities, and the benefit of using them over VSCode of JB is that you get to be a part of these communities that attract the best talent, give the best troubleshooting advice, and share advanced configurations for everything and anything you could possibly ever want. They are programmable programming environments first and foremost, and that attracts people who are good at programming and like to hack on stuff.
Technologists who choose the propriety path of least resistance when it comes to their most important tools I think are ultimately missing out in a lot of ways, least of all is the actual editing experience. A craftsman should understand his tools inside and out, and picking something you can't fully disassemble and doesn't have the breath of knowledge a tried and true open source tool ultimately becomes just as frustrating as the initial learning curve of these older tools.
I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
If you worked in C++, then visual studio has been around for 20 years - visual C++ for 10 years before that. If you use java, then intellij has been around for 20 years. Pycharm for 15 years. If you're writing JavaScript, I don't know what to say because the framework du hour has changed so many times in that time frame that I don't think the tool saves you much.
> Technologists who choose the propriety path of least resistance when it comes to their most important tools I think are ultimately missing out in a lot of ways, least of all is the actual editing experience
Equally, I can say purists or idealogists are so concerned with theoretical changes and breakages, and so afraid of the possibility of something changing that they miss out on game changing improvements to tooling.
I think the way people use IDEs is a lot deeper than just reducing them down to "purist" or "ideologist". That sounds a tad bit dismissive for something that is essentially your trade tool. It's akin to saying all keyboards are created equal because they have the same keys. The way you lay the thing out and the perspective that you build it for matters quite a lot. Distilled in a quote, "the whole is greater than the sum of the parts."
I got used to JetBrains' key mappings when I was at my last company, I also adored their debugger. My new company uses VSCode and I started down the venture of remapping all of them to JetBrains keys. I ended up with a lot of collisions and things that no longer made sense because the keys were mapped using a different perspective when laying them out. I'm sure I'm not alone being in a pool of engineers that primarily navigate using their keyboard.
VSCode's debugger is better now, but it still doesn't really stand up to JetBrains'. On the other hand, launching VSCode on a remote box is much easier and their configuration is much more portable with their JSON based settings files. I like using VSCode, but it took me months to get up to speed with how I navigated, and more generally operated with, JetBrains' IDEs.
A person using Vim or Emacs has had best in class integration with the unix environment, modal editing, and remote development. Today, both editors have integration with VCS via fugitive or magit, fuzzy finding, LSPs, tree sitter, and code generation tools using LLMs. These tools have not stagnated, they've continued to evolve and stay best in class in many areas. So the "one tool is better than the other" argument doesn't really sway me. My point still stands that the community and open architecture are more important than any one editing feature.
> Equally, I can say purists or idealogists are so concerned with theoretical changes and breakages, and so afraid of the possibility of something changing that they miss out on game changing improvements to tooling.
Blindly following the crowd is also dangerous. Making choices based on principle is what allows good things like open source communities and solutions not swayed by corporations to exist, even though they might require more up front investment.
> I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc. because they claim it makes things easier when they have to use an environment that they can't as easily configure, like sshing into a shared box without a separate user for them to customize. This mindset has always been hard for me to understand; not only does it seem like they're optimizing for the rare case rather than the common one, but it seems like they're actually just lowering the quality of their normal experience in order to make the edge cases feel less bad without actually improving them at all
>I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
Vim police has issued your red warrants. Justice will be served.
Jokes aside, I'd say yes. I have worked with Eclipse, NetBeans, JB and nowadays I'm happy with VS Code. For a polyglot, it's the best out their at price point $0.0 and tooling is pretty good for me.
I'm doing Python, Go, Typescript and occasional Rust without missing anything.
Few keystrokes faster with command kata would not going to save years of labor. Actuall effort in software engineering is not in typing text or in text editing. Not at all. The battle is far far beyond that and bigger than that.
The best part is, you don't need to choose between using IDEs and your favorite text editor! Most modern IDEs with proper plugin support can be configured to provide a superset of Vim's functionality. I personally use IdeaVim on the IntelliJ Platform [1] with AceJump [2] and haven't looked back. You can import many of the settings from your .vimrc and it interoperates fairly well with the IDE features. Although I prefer Vim keybindings and it is technically possible to hack together an IDE-like UX with ctags and LSP, the IDE experience is so much better I wouldn't even consider working on a large Java or Kotlin project from the command line.
I think you missed the point of my post. The value of Vim/Emacs isn't the modal editing or key chords. It's the community and architecture, which you lose if you're still using JB with a frankenport of Vim on top. In fact, I think what you're suggesting is the worst of both worlds - a reimplementation of Vim on top of an already resource hungry and complicated IDE that's supposed to let you do things with a mouse. So you're left guessing whether something from real Vim will be the same in your Vim, plus you now have two competing environments for ways to do things, and you have to wait for JB to implement features that (neo)vim have already implemented, without supporting the opens source communities that did the work in the first place.
You also lose the killer feature of Vim, which is being able to work over an SSH connection on any sort of device, even those that don't have a GUI.
I've seen hugely talented folk on vim/emacs/emacs+evil, and on VSCode/JB. I think was the latter tools do, it make some of the advantages of being proficient in vim/emacs/regex available with less learning curve.
Currently there are some combinations that simply best-in-class: VSCode+TS, JetBrainsIDEA+Java/Kotlin, VisualStudio+MicrosoftGuiStuff. vim/emacs may come a long way in these areas, but cannot beat the integration level offered in these combinations.
Also, you mention "proprietary", but JetBrainsIDEA and VSC are opensource to some extend, which does improve community imho. But, the fact that they are less "open access innovation" projects, and more company owned is clear to everyone.
Finally: AI will come to software devt, and I wonder if AI tools will ever be available on true open access innovated IDEs.
> I've seen hugely talented folk on vim/emacs/emacs+evil, and on VSCode/JB. I think was the latter tools do, it make some of the advantages of being proficient in vim/emacs/regex available with less learning curve.
Take Reddit and Hacker News as a fitting analogy, a community with a higher barrier to entry/more niche will be smaller, but the quality is vastly improved. There's still going to be people who sit in both communities, and smart people in both, but it's not controversial to say that an initial learning curve tends to attract people who can pass the learning curve and are motivated to do so. Another great example is the linux kernel development process.
> Currently there are some combinations that simply best-in-class: VSCode+TS, JetBrainsIDEA+Java/Kotlin, VisualStudio+MicrosoftGuiStuff. vim/emacs may come a long way in these areas, but cannot beat the integration level offered in these combinations.
Integration in some ways, in other ways a terminal based tool that adheres to the unix philosophy is more integrated with thousands of tools than an IDE where every tool has to be converted into a bespoke series of menu items. Just look at fzf, git, rg, etc. integrations in Vim. They are only lightly wrapped and so the full power of the tool shines through, and it's easy to customize it to your specific needs, or add more tools.
> Finally: AI will come to software devt, and I wonder if AI tools will ever be available on true open access innovated IDEs.
In the same vein, AI tools that act as black boxes and are integrated in the same transparent way as git or rg in Vim at least allow the editor to remain full transparent to the end user, and leave the complexity in the LSP or bespoke tool. I really see no difference between how AI tools will relate to editing as LSPs do today.
In my anecdotal experience the best developers are the ones that don't overly focus on their tools at all. One of the most proficient developers I've known was perfectly ok programming on a little square monitor with Visual Studio where the code window was 40% of the screen real estate.
It doesn't have to be that extreme but it reminds of hobby craftsman who focus on having a garage full of the tools of the trade while never finding the time to work on a project with them.
At some point in a developer career one shifts from a tool focus to a work focus.
I used to be picky about my operating system and often would spend time making the tools that I wanted or preferred to use work within the project dev environment, as opposed to just using the tools my employer provided. It usually ends up just being easier, and if everyone is using the same tools then pair programming or collaborating becomes easier, too, as compared to having to deal with the one stubborn dev who insists on using Emacs on a Mac when everyone else is using Visual Studio.
This has been my experience as well. The most productive people are the ones who actually focus on the work instead of wasting time configuring a perfect editor.
Mileage varies, even the most ardent vim user I know gave up and switched to VS Code this year. It's just too much to try to keep up with when projects and technologies change. I've programmed in C++, Go, Python, Java, and Angular just in the last year. I can believe that there's vim plugins to handle all those, but the energy it would take to find auto-complete and navigation and formatting and debugging and any number of other out-of-the-box IDE functionality is more than I'd like to thing about. Then there's the associated tools - Kubernetes yamls, swagger, markup, Makefiles. In IDEs they are only one plugin download away.
I love vim, I used it exclusively for years when I was doing C/C++. I still ssh into servers a lot and use it pretty much daily. Still, I'm far to lazy to try to turn it into my full time development environment .
> I can believe that there's vim plugins to handle all those, but the energy it would take to find auto-complete and navigation and formatting and debugging and any number of other out-of-the-box IDE functionality is more than I'd like to thing about.
Well, I'll be the bearer of the good news, then!
NeoVim has a native LSP client which unifies all auto-complete/navigation/formatting into a single plugin, only requiring you to install per-language LSP server.
As for debugging, there's also DSP (Debug Server Protocol) which NeoVim doesn't have native support for, but there's a plugin for that.
VSCode is a significantly more pleasurable experience working over a 100ms+ network connection than either vim or emacs (this being the reason why I switched away from emacs/tramp myself).
Visual Studio Code is currently where all of the tooling effort is focused. For the best tools with the best integration you should be using it or, depending on language, JetBrains. These are easy to use and developers can be productive in them from the word go -- without extensive customization. Hell, if you open a file in a new programming language, VSCode will suggest plugins to install.
You do NOT want to build integrations by yourself. You want to build whatever product you're building. The fact that vim and emacs users do this is yak-shaving that pulls precious time away from the task at hand and serves as a distraction for editor fetishists. Do not become an editor fetishist. Modern IDEs help you become more productive faster and give you more support for things like debugging. (You are using a debugger to inspect and analyze your code, right?)
the ide is not more complicated than your customized Vim setup once you get it close to functionality (you won't). I use all keybindings anyway, so it's not like the UI adds anything bad?
I switched from lightweight editors to IDEs many years ago and my productivity went up A BUNCH - even if sometimes it uses gigabytes of ram. so what? Even my old used machines have 8-16gb of memory now.
I would honestly much rather hire people that work in IDEs than people that like to "hack" on their vi/vim/emacs setup. The number of times I've been in a screen share with someone while they're trying to code or debug something with Vim etc, it just feels so slow to watch them work that I get that embarrassed-for-them feeling.
>"Technologists who choose the propriety path of least resistance when it comes to their most important tools I think are ultimately missing out in a lot of ways"
One nice side effect of modern TUI applications is that they can be distributed via Docker Hub as platform-agnostic applications that just require a compatible color terminal.
E.g. here's my C64 emulator running in Docker (it's a real C64 emulator underneath, but only renders the C64 PETSCII buffer via ncurses, e.g. no graphics or audio output):
Yes, the Borland TUI was pretty good. But nothing came even close to what we had on the Commodore 64 with the X-Ass Dev Kit. You could code in a nice TUI with syntax highlighting. Press a key to assemble in a split second, execute the program, press reset and be back in the TUI exactly where you left off. And this with source file > 64 kByte, creating executables that occupied the complete memory space of the computer.
This article completely ignores the Macintosh and the greatest IDE ever, which came out in in the mid-80s: Coral Common Lisp. It ran on a Mac Plus with 1MB of RAM and it was fucking awesome. It included a drag-and-drop interface builder that let you build a complete app in literally a matter of minutes. Nothing I've seen has come close since.
The descendant of CCL runs on modern Intel Macs. (It also runs on Linux and Windows but without the IDE.) The modern IDE is quite a bit different from the original. In particular, it no longer has the interface builder. But it's still pretty good. It is now called Clozure Common Lisp (so the acronym is still CCL) and you can find it here:
If you want to run the original that is a bit of a challenge, but still possible. The original was never ported directly to OS X so you have to run it either on old hardware or an emulator running some version of the original MacOS, or on an older Mac running Rosetta 1. In the latter case you will want to look for something called RMCL. Also be aware that Coral Common Lisp was renamed Macintosh Common Lisp (i.e. MCL) before it became Clozure Common Lisp (CCL again).
This looks like it might be a promising place to start:
The IDE was Project Builder, Interface Builder was a separate, as the name implies, builder for interfaces that could then be connected to Obj-C code in Project Builder. They continued as separate apps even after Apple bought NeXT and shipped Mac OS X, until they unified the two into Xcode.
Turbo Pascal and Turbo Prolog - those were the days.
Borland had the greatest products, and the accompanying books were always well written, used beautiful fonts, and, not less important, smelled nice.
If my memory serves me right, Borland even released their Text User Interface (TUI) library for developers to use in their own applications.
Loved the concluding question. "So the question I want to part with is: have we advanced much in 30 years?"
Every time I see all the bloated software we are putting out. Is it really worth it?
One program that does it all vs many programs that do one thing really well. Oh, maybe someone should write about this concept, it maybe interesting to ponder :)
30 years ago, I used Trash'em One on the Amiga. It was a text editor, 68000 assembler, debugger and memory monitor in one.
I preferred it over its predecessor Asm One (which had been based on Seka), but I don't remember what feature it was that made me switch.
Thirty years ago is 1993, and I was a junior dev using CodeCenter on SunOS. It was a nice editor/debugger with a C interpreter mode that iirc let you inspect aa variable's history and un-execute lines of code.
A few years later I was using SparcWorks on Solaris. When I realised you could pause on a breakpoint and hover the cursor over a variable in the editor to see its value, my brain nearly fell on the floor.
A few years after that I moved to PC development using Visual C++, and then Visual Studio 97 on NT4. Drag and drop UI builders for Windows and Web.
And 30+ years later I still spend a significant part of my working day in VS.
I love the aesthetic of Borland Turbo TUIs. I went back and tried to use TurboVision some time last year. It was not good, to say the least. Would be pretty cool if VSCode were themable to the extent that WinAmp was, so we could reclaim that old style.
Is Doom Emacs really 500 MB? How did the author determine that?
I use vanilla Emacs and I believe it was closer to 100 MB when I installed it.
Related: I’ve spent a lot of time trying to find a development setup that runs on low-end hardware (as a reaction to modern bloat, and also as a way to minimize distractions). It has many flaws, but Emacs with Common Lisp is my current sweet spot of “price” (resource requirements) to “performance” (features+speed).
We used Turbo Pascal and Turbo C++ for my high school classes, and I have very fond memories of both. This must have been on Windows.
Borland really had a series of these fantastic products, it's a shame they are no more. The only modern company in this space is JetBrains, it seems, so the niche is small.
Turbo Pascal and Turbo C++ are still used to this day in some high schools and even college intro courses. Of course nowadays you need Dosbox to run them on modern computers.
30 years ago people were using Interface Builder already. Admittedly not that many, but the drag and drop interface is still there integrated into Xcode.
They were, and had it not been for Apple's reverse acquisition, it wouldn't be there in Xcode today.
My graduation thesis was porting a visualization particles engine from NeXTSTEP/Objective-C/OpenGL into Windows/Visual C++/OpenGL, as the department was seeing the end of NeXT and they wanted to keep the research going on.
My supervisor had a NeXT Cube getting dust on the office corner, waiting to be collected.
I found myself lack of energy and time stepping into my 40s and vowed never to waste time “learning” cool editors such as Vim and Emacs.
VSCode is now my one stop editor of choice on Linux and VS on Windows. I also use Jetbrain editors for work.
I’m done. For people like me, who write SQL and Python for data pipelines, the Jetbrain IDEs are no-brainers. We don’t actually get the time or energy to do a lot of side projects so it doesn’t make sense to learn advanced editors such as Vim and Emacs: 1) These two need a lot of muscle memory just to start using it, but we don’t use it on a daily basis, 2) I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
Funny because I entirely agree with you, even though I do the exact opposite. Everything I write is in vim because I'm too lazy to learn an IDE which may or may not still be around in 5 years. I use 0 plugin and 6 lines of .vimrc config which I know by heart, so I don't care if I'm using it locally or remote, I can always get started in 1 minute.
I tried to install plugins but there is always something that fails somehow. Nvim distributions don't install and run out of the box for the most part, I get weird errors regarding lua or something and just give up. As for VSCode I wrote my first python project using it a couple weeks ago (I'm not a developper) and it's alright but a few things annoy me, like the integrated terminal and some things getting in my way.
At the end of the day, each of us should chose whatever we feel comfortable with. I spent maybe 2 hours in my life learning vim movers and never looked back. I don't even use tmux or anything, just open 1 or 2 terminal windows and alt+tab between them, with the occasional :split or :vsplit command.
There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.. you still have to invest and devest everytime a new wave comes. Meanwhile emacs is still mostly emacs. I understand the dread emacs can impose on you, from old keybinding cultures and elisp but there's something timeless and freeing in emacs.
I'm in my late 30s. So maybe not so far away from the age of lack of energy :P
I like JetBrains a lot. Things work seemlessly and easily integrate with external tools that make up the whole experience. But from 2012, I tried to rely as much on shortcuts as possible, for one simple reason, the mouse.
There is no problem with using the mouse. But everytime I have to use while focusing and coding, I find that that small gesture to move my hand from the keyboard to the mouse a bit flow breaking.
I have to move to the mouse, do a thing or two, then find my way back to the J key notch.
I like what NeoVim and emacs bring with regards to the reliance on the mouse. They allow for maintaining the same posture most of the time and focus only on typing.
I dislike how brutal they are at learning how to use them to full potential, and that making them into IDEs takes ages of IDE building rather than project coding.
I like Helix. Which takes a lot of inspiration from Vim/NeoVim/Emacs. But require no configuration to get you going right away.
The documentation is easy to read, as of now there is no plugin system but there is a builtin integration with a lot of LSP servers for most of the popular languages by default.
Keys and navigation is easy, it even shows a helper popup to show you which key to use next.
My suggestion is, if you ever want to start a new silly project, and you're feeling free to take it slow for 2 days. Try using Helix on said project.
PS: Helix isn't fully complete by any means, but it really is capable of doing everything you want in many projects without being a hindrence if you can adapt to the lack of some built-in features like git and file tree. Its annoying but I am less upset about it and use alternatives
Honest question: are other jetbrains IDEs "feel" similar to the Android Studio one that can be downloaded for free?
I installed it a couple of weeks ago to modify some android app, and boy it gave me vibes of the old Eclipse : sluggish Java feel , with "stuff" happening all around and being slow to render basic editor stuff.
I wouldn't consider myself a vim user, but learned the basic keybindings awhile back (IMO modal editing is the correct way to edit). Knowing those makes it much easier to bounce between IDEs. Sometimes I don't realize if I'm in VSCode or IntelliJ (especially the new UI) until I try to run something.
> I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
I've worked with good programmers who literally hunt and peck. It drove me nuts, but as most will agree, typing is rarely the bottleneck when programming. I've also worked with people who I would consider vim power users, and while they were faster at typing out some tasks than I am, I found they were often typing/moving around the file as their method of thinking. Whereas I might reach for the mouse and scroll around instead. Again, typing speed is rarely the bottleneck.
I'm a heavy Vim user but I agree with your sentiment. I learned Vim during some down time in my first job out of college. It is a great skill to have in my opinion. It helps me complete complicated text editing quickly and easily, especially operations that I otherwise would never have attempted without it, but I never would have had the time or energy to learn it later in my career. I don't think learning Vim or Emacs is a waste of time but I can see how it is definitely not a priority when you have so many other things to do and little time to do them.
I am a life-long vim-er and I only use probably 30% of its features and thats ok. I learn new things all the time, sometimes adding them to my repertoire, sometimes not. There's so much time that can be wasted if you mess around with configuring tools but either fail to remember to use them or fail to get them set up. I wanted to set up ctags and tried a few times, but fell short of memorizing the forward-back shortcuts and got frustrated at the delay when it goes off scanning my HDD instead of the local code 1-2 directories away. so I just gave up.
For me, cool editors are vscode and jetbrains. I've tried to make them my default editors many times but always go back to vim (which I've been using for decades).
I agree that since you are well versed in Vim, it doesn’t make sense to switch unless for something vastly better —- which I don’t see in any existing product.
I have tried to use VSCode more, but, the original emacs keyboard movement is burned into muscle memory. VSCode has a keyboard mapping for emacs, but, its does not feel right. At the end of the day, who cares? Its just a tool, whatever works.
Likewise. I'm 46, and started my career in the late 90s using mostly light editors on Windows (Homesite, etc). Along the way, I've tried a few times to really dive into vim, but just couldn't see the advantage over editors like VS Code, Sublime, Atom, or some of the editors popular before then like Eclipse. However, I do feel comfortable enough in it that I can edit files on servers/containers, which is something I feel is useful for everyone.
I started with emacs. I love the buffer / windowing system and the on-the-fly macros. Also being able to do everything with the keyboard.
But the time spent getting multimode up or good autocomplete when you can simply fire up something like jetbrains IDE, having most of your ecosystem tools integrated the second you launch it makes the decision to switch easy.
Also, dev machine tend to have a lot of resource nowadays so the RAM hungry IDEs are not a problem.
VSCode has solved so many problems for me. The only time I step out of it is when I run into something that might be a configuration issue. For instance, if I’m programming an Arduino, and it’s not working, it’s worth hoping over to the official Arduino IDE to make sure that the “supported” way doesn’t work as well.
Otherwise, VSCode solves almost all my problems, and virtually all my key-bindings are identical.
wow, i had the same experience. reaching my 40s and decided to drop all the cool kids stuff. i used to have emacs/scheme evangelist phases in my life, now i do all my coding using enterprise languages and tools.
VSCode and JetBrains are better overall, but many of the good editing features of Vim are available via their respective Vim emulation plugins. It is still worth it to learn and use Vim mode for efficiency (in my opinion).
they're really not that difficult, its not a badge of honor to use them. I used xemacs and liked it ages ago, and I still use raw vim for quick edits or views occasionally. The reality is modern ides are simply better for 99.99% of use cases. I might not use idea for open log files that are massive, and that's about it.
Oddly enough, I never used them at the time. It was the CLI compilers, and makefiles. Possibly because most of the work I was doing was cross compilation for embedded systems, not targeting DOS nor Windows. However it was often using Borland/Turbo C and/or Metaware High C, both as DOS based compilers. Occasional y some assembly, or (DOS based) cross compilers for other CPUs (8051, Z80, etc).
Possibly the experience was different for folks not predominantly doing cross system development.
So the editor was usually BRIEF, which could be set up with per file type "compile", rules. Being a multi-file editor, one could "compile" the makefile, hence build the complete system. This would then run the compiler, and jump to the first error; plus commands available to jump to the next error in sequence.
On the occasions I needed something better for search and replace, I'd use a DOS version of vi.
When working on a local (DOS based) tool, one would occasionally have a TSR version of a help manual available, but generally the printed manuals the products came with were preferable.
As to a retrograde step when switching to unix/linux/bsd based development, not really. The combination of Job Control to switch between suspending the editor and running the compiler, together with virtual terminals where one could have man pages open covered most bases.
Back then BRIEF was also an amazing development environment. Now it was not so much an IDE and more of a programming editor, but it was still amazingly good for software development.
I'm surprised there's no mention of QBasic that shipped with MS-DOS >= 5.0. This was built on top of EDIT.COM, and while it only ran a BASIC interpreter instead of compiling an executable like full-blown QuickBasic.
IIRC it had a rather extensive help lookup system for functions, data types, reference tables, error codes, and whatnot. You could step through your program, set debug points, all without exiting to DOS. It was my first ever exposure to an IDE, I thought it was pretty nice for what it was.
I loved QBasic. That integrated help system also came with extensive sample code for each function, including some full programs. Copying and modifying those was a huge boost to learning how to program.
Those Borland IDEs, a show of hands for Turbo Basic as well, were the main reason why I never liked the UNIX development experience, until a professor showed us XEmacs, at the time much more feature rich than Emacs, and vi was still vi, not vim.
Thankfully with KDevelop, Smalltalk, and when Java started to make IDEs more common on UNIX, I no longer needed XEmacs.
Ironically for all IDE-haters, even James Gosling, inventor of XEmacs, says people are missing out not using IDEs, he surely moved on from Emacs ecosystem.
Nit: James Gosling implemented Unipress Emacs aka. Gosmacs, not XEmacs (with a lot of licensing sturm-und-drang). XEmacs was forked from Gnu Emacs at Lucid, by jwz (Jamie Zawinski)
There’s a ton of editors that are all roughly equivalent for writing C++ code. Vim, EMacs, VSCode, 10x, whatever.
But Visual Studio is still hands down the best C++ debugger. And nothing else even comes close. Which is a real travesty.
RemedyBG is making progress. But it needs a NatVis equivalent and it needs to be way more reliable. It fails on major projects with obnoxious regularity.
One thing these IDEs had was an integrated debugger.
It seems Unix/Linux really got a nice integrated debugger with ann IDE and gdb is powerful, it is very cumbersome. Hence, it seems there is a lot more printf debugging on Unix, and less use of debuggers than say on Windows where Visual C++ and Borland Turbo C++ both had very easy to use debugging integrated into the IDE.
Agreed, for the most part debugging has gone backwards (aside from Xcode, Visual Studio 20xx) and was always pretty bad on UNIX. Still amazes me that there isn't a really nice, batteries included TUI debugger (e.g Periscope!).
Did a lot of programming without an IDE. Then some years ago, tried an IDE: Opened a project. Looked at the resulting directory (folder) and saw ~50 files with what I knew nothing -- hadn't even started the work yet.
Got rid of the IDE and returned to my favorite tools and the software I was writing.
My favorite tools work fine, and in particular in the directory I'm in I actually know what each file
there is, what it is for, what is in it, where it came from, etc.
In my work, I need to do some programming, that is, software development. So, I do it.
Difficulties are nearly all from poor documentation of other software I need to use. The parts of the programming that are really mine are like cooking lunch -- no problems for my part, but if the pepperoni is not good, that's a problem. To me, programming is, define some variables to store the data, have expressions to manipulate the data, If-Then-Else, Do-While, call-return, input, output, and that's about it.
I do wonder what the easiest, most straightforward path to a full TUI IDE would be today. Perhaps starting from the codebase of a lean graphical IDE like Lapce and adding a TUI-powered backend. (Note that text editors do exist with that kind of interface, the real gap is wrt. the IDE features including LSP and DAP interop.)
Does anyone here feel kind of trapped by their IDE now?
PHPStorm + Laravel Idea + the laravel-ide-helper package provides such a great PHP/Laravel development experience that I haven't been able to replicate in VS Code or Sublime. But chowing as much RAM as it does, it feels sluggish. Or at least, not as snappy as the alternatives. But I just haven't been able to find a middle ground with the lighter alternatives.
Running the IDE as a thin client with Jetbrains Gateway sounds like a decent solution, if your backend server is close enough for latency to feel okay. From a ~4GB PHPStorm usage, PHPStorm-via-Gateway on GitPod was 1.2GB max.
At the lower tier with the 8GB RAM, it's the most affordable device that will outlast power cuts that are frequent where I am - cheaper than getting a backup power solution. Getting more RAM is a ridiculous cash grab by Apple.
It's a rock and a hard place.
>4GB RAM is very little usage for advanced IDE
Java is awful with RAM in general. Decent text editor plugin setups can get close to the Jetbrains suite for what I do, but it's just a few small UX & plugin papercuts that make the difference. And I heavily doubt that those tools I prefer are that heavy compared to other editors.
Interesting mention of Sidekick Plus, there was a complete SDK for it which I don't think ever got released anywhere (I had a copy as I was working for Borland at the time). It allowed multiple documents to be open at the same time.
In the early 2000s, back in my homeland, high schools were still stuck using Turbo C for programming classes. This was mainly because there weren't many free and lightweight C IDE options available for Windows (I know Turbo C is not a free software technically).
While Dev-C emerged as a possible alternative for console programs and programming contests, it wasn't enough for developing native Windows GUI applications without shelling out for Visual Studio.
This limitation ultimately led me and some friends to explore development on alternative platforms like OS X and Linux. Ironically, even to this day, none of us mastered the WIN32 API.
Fond memories learning both Pascal and C when at high school with 486 Compaq machines and the Turbo compilers.
Not long ago I configured DOSemu with Turbo C to do some bare bones graphics development but I just couldn't get used to it.
Does anyone know or recommend a setup where coding takes place outside DOSemu but yet the compiling/execution takes place in DOSemu? (I mean calling all the build chain outside DOSEmu).
I've seen in an older HN post that someone setup a retro IDE with VSCode but I'd like something more Vim like instead of this behemoth.
I agree with the article. Turbo Pascal was terrific. There is some kind of psychological thing that has me using neovim in a terminal all the time for many years.
I guess it's convenient for ssh. But I miss the affordances of Borland IDEs. Even last night I was working on a web application and was tempted to add a menu at the top of the page, remembering how useful they were back in Turbo Pascal and such.
Turbo C/C++ was my first IDE, when you know all short cuts, it was quite fast. Then came DJGPP with RHIDE...and for many years, IMHO, Visual Studio 6 was best for kid ( and window user ) like me.
I was a TA in an "Intro to Compute Science" class in the naughts, and using Borland C was quite popular among students who were on Windows.
I never heard a single student complain about the IDE, even though most of them were used to GUI apps only. It was very intuitive and convenient to use. I wish we had nicer TUI tools today - I often miss them when I work remotely over a thin connection passing through a couple of proxies/gateways/etc which have trouble with X or VNC traffic.
My favorite part of late 80s early 90s C/C++ dev was the shitty auxiliary monitor used as a dedicated debugger screen. I swear I STILL find situations where I want that back.
I was always kinda partial to the Borland IDEs. I even used the concept on Linux for a while in the form of "RHIDE". It wasn't bad UX but the software was pretty badly written so in the end I dropped it. I never enjoyed anything as bare bones (or requiring such a learning curve and setup of adding) as vim. Right now I use VS Code. Not a huge fan of it and I really wish it was available as a TUI application but for now it seems to be the best around.
If you look at his screenshots you might think you were limited to 80x25 but with EGA and VGA you could pick a different screen size and get more vertical lines.
At the expense of vertically squished fonts, which I hated the look of. I would have been more likely to use it if it had a similar increase in the number of columns to keep the font at the correct aspect ratio.
On the Mac side, THINK/Lightspeed Pascal had all of the same unmmatched mod cons of Turbo Pascal: lighting fast compile times, unmatched symbolic debugger that understood record types and Macintosh handles with a variable watch/execute statement window, auto formatting. It was sad that the Mac world slowly converted to C/C++ as the "flag carrier" programming language.
Borland Turbo C and it's debugger helped me implement my 1st scheduling optimization algorithm, get into production and got me a promotion. Ported it over to IBM mainframe with the help of a colleague which reduced run time to few minutes compared couple of hours on DOS/486
It looked so clunky compared to what my colleagues used in their DEC and SGI (6 processors I think) workstations had, but got the job done
In 1989, I got a IBM AT, with VGA. I flipped from a Herc card, with 25 lines, leaped past EGA 43-line mode into VGA 50-line mode. Turbo Pascal, and SideKick ( or psychic ) all ran perfectly. Paradise VGA w/ 512k. Sony 15" Trinitron, very sharp. Why don't other people program in this?
Wideprint had a 132 column mode for Lotus 1-2-3, and again, SideKick jumped in perfectly.
Seems a bit quick to dismiss modern TUI editors. Emacs in terminal mode has feature parity (almost?) with the GUI version.
And by the way classic curses like menu bar can be opened in text mode with M-x menu-bar-open which is bound to <f10> by default. You can even use mouse with xterm-mouse-mode.
The one he was looking at was text menubar emulation which is pretty powerful too if you take a minute to appreciate it.
I hope someone from Embarcadero is paying attention to this thread. They have had some great IDEs but their primary attraction was the price point and the ease of use of the products. Please make Delphi affordable again.
Considering that Delphi can be used for Android, IOS and Linux development as well, it would be a great tool - if it weren't for the insane pricing.
Coming up for retirement and I have made a nice business using Delphi; it's been the right tool for the right job and that is developing Windows programs.
I understand why Embarcadero did it, but for the dozen people who actually use Delphi for any OS other than Windows, and any CPU other than x86, they really should not have bothered.
30 years ago I was using vi and the shell on a Wyse 85 terminal.
Nowadays I used vim and the shell in one of many terminal windows on one of many workspaces.
Every now and then I try an IDE but I always find the loss in productivity and the lack of discoverability to be hampering. I'm there to get work done, not to stare at cartoons and fumble around for wherever the mouse or cursor has disappeared to again.
I forget if it were a MS or Borland thing, but I recall some of these DOS IDEs having an "expert mode" feature in the menus where you'd get, by default, only the most useful features, but could then turn on all the menu features by enabling said expert mode. Anyone remember this? Some tools (VS Code..) could sorely do with this today, I feel.
Nobody (yet) has mentioned Microsoft PWB - Microsoft's Programmers Workbench for their C compiler, around 1990. It's what all the Microsoft engineers themselves used when writing code for Windows, WinNT, OS/2, etc. It was essentially perfect for its time.
ObjectMaster by ACI was pretty much the best OO IDE at the time. Pretty much everything on the Mac kicked the shit out of these pathetic and crappy DOS/commander interfaces that are linked in the article.
Unfortunately, there don't seem to be any screenshots of it online anymore due to link rot.
Borland C/C++ 3.1 came in the largest by volume and by weight shrink wrapped box ever due to inclusion of printed library and API references for DOS and Windows and other tools.
Borland-branded products were the pro versions compared to the Turbo-branded ones.
If any dev out there is looking for a challenge/cool thing to do, here it is: a TUI DE following the practices of TurboC/TurboPascal, CUA visuals and keybindings from edit.com and support for multiple languages and LSPs.
So I've been using vim as my IDE for the last ten years. I've really enjoyed using it, but VSCode is super duper popular. Has anyone like me converted? If so, are you still using Code or did you go back to vim? If so, why?
I gave VSC a shot. It's the stupidest thing, but I just can't get over how the side bar (not the file explorer, but the little activity bar that you can open the file explorer/plugin menu/etc from) keeps re-appearing every time I open certain things. I know it's petty, but I can't get over it.
I was able to, mostly, get things to work the way I wanted in it, but that ended up meaning I turned it into basically my vim setup.
I've moved to jetbrains products at work. Same story there, I basically turned it into vim, and hid all the sidebars (but it does let me do this). Mostly I'm using it for the debugger, the jetbrains debugger is legit.
Still use (n)vim at home a lot, especially for anything that doesn't have a dedicated jetbrains ide.
Other than that, the only thing I've really had problems with is that graphical editors all seem to think in terms of files instead of buffers, and there's no equivalent to vinegar. I think that really throws me the most.
Moved to vscode with the neovim extension (vim mode was slow for me over large files). vsc is super customisable, and you can remove all the tab bars, side panels and anything else you don't use fairly easily. It's also far more stable than the neovim ecosystem, i don't have time to mess with neovim plugins breaking bi-weekly anymore
I remember using Borland Turbo C++. It was the most convenient piece of software to get started with programming. If I had been introduced with anything else, I would have found it much more difficult to cross the initial curve.
I fondly remember Borland C++ builder - it allowed me to write shareware apps for Windows without having to learn the low-level MFC API. I was a hobbyist, and it scared me :)
30 Years ago Watcom would be ripping through Borland's assumed monopoly and rapidly becoming the most used C/C++ IDE, only to have Visual Studio do the same to it in 2-3 years time.
15 year old me could use the Turbo Pascal debugger well because it was so intuitive. Now I’m just not comfortable with using debuggers at all and I keep spamming prints in my code.
I recently started building a little desktop app using C# .NET WinForms, and it was a tiny bit clunky at times, but strongly reminded me of building VB4 apps.
30 years ago - and from about 89-94 - my IDE was DataViews. Still all these years later I don't know of any IDE that can create such graphical interfaces.
I'm not a fan of any IDE brand or company. I'm a fan of features. Any respectable IDE must have the following features:
- jump to declaration
- autocomplete of fields and methods of an object
- autocomplete or tool tips for function arguments
- code templates
- find all the usages of a variable, type or function
- rename variables, function, types etc. all over the code base(and do it correctly not blindly like with sed)
- select a piece of code and extract it into a function
- select multiple fields and methods and extract them into a separate class
- highlight pairs of parentheses, brakets, curly braces and be able to jump between them
- highlight searches
- show line numbers
- search/replace text in current file or over multiple files(aka grep and sed but integrated into the UI)
- be able to open a terminal in a pane
- search for a type all over the code base
- search for a global function or variable all over the code base
- display tree of included files(for languages that allow including other source files like C++)
- display tree of subtypes/supertypes of a specific type
- display a list of all overrides of a method and be able to jump to them
- semantic checks(e.g. check that the types of the arguments in a function call match those from the function declaration - of course for languages that have a type system)
- display syntax/semantic errors as I type
- a file explorer should always be easily accessible
- automatically select the current file in the file explorer; be able to turn this behavior on or off
- Copy the full path of the current file to clipboard
- Copy the name of the current file to clipboard
- Autoformat the code
- Autoindent
- Syntax highlight
- debugger integration
- build system integration
- display an outline tree of the source code ine current file
- have a local history of all the changes to a file
- version control integration
- diff between current and previous version of the current file
- search files by name in the entire code base
- when many editor tabs/buffers are opened, search through them by file name
- spell checking in comments, be able to turn it on/off
- generate documentation from comments
- fold/unfold code blocks
- replace tabs with spaces
- show special characters
- block editing
- place coursor in multple places and perform the same editing changes in multiple places at once(like in sublime)
- jump over paragraphs
- jump to beginning/end of file
- open documentation of function/class/type/etc. under the coursor
- set bookmarks in code
- have a history of searches and be able to redo older searches
- list all TODOs/FIXMEs from all over the code base
- split panes vertically/horizontally
- textual autocomplete (meaning autocomplete if identifier is already present in current file)
- linter integration
- UML diagram generation
- erase the current line with a single key binding
- move current line up/down with a single key binding
- display object instance tree
- and possibly many others that I just can't remember right now...
Now I don't care if it's vim, emacs, vscode, eclipse or jetbrains offering these features. From experience I learned these features make me most productive...coupled with command line tools it gets even better. So if these features/tools are available in an IDE/tool suite then I'm a happy programmer and I will use them. I don't have time to be a fan of this editor or that editor...even though I do like to enable vim key bindings if they're available once in a while.
IMO the real loss in IDE tech is the speed that visual basic 6 gave you to make desktop guis.
Web and mobile development (which I have done all 3) are significantly slower than what you could do with VB6. It's really strange why we haven't gotten back to it.
VB6 was fantastic. The language was terrible, but the IDE was the best way to make GUIs that ever existed. The Windows 98 era was excellent for UX as well, with every element on the screen having an accelerator key, consistent menu guidelines, consistent visuals, keyboard shortcuts, etc.
It was just brilliant.
VB6 worked because the environment was simple. GUIs are simple when you don't need to do any styling, do not require any special modifications and most importantly you don't need responsiveness. All of that, and you need a special environment and operating system to run the GUI. Web front-end are a completely different game in that regard.
44 replies →
I think Delphi was slightly better. The components in Delphi were more powerful at the time. But the general idea is the same.
C# with WinForms is still usable today and provides a similar experience. Although the design language has fallen out of fashion.
1 reply →
The GUI WinForms editor in Visual Studio 2022 is a direct descendant of the one in VB6 and has all the exact same functions that I remember from VB6.
Let's not forget Delphi and OptiPerl https://www.uptiv.com/free/optiperl/ Till date I have not seen any IDE that could reproduce its amazing box and line coding feature
Delphi was even better. Great IDE, great language, compiled executables. Too bad that paradigm didn't survive the web.
>> but the IDE was the best way to make GUIs that ever existed
It was Lifted in spirit from NeXTstep's Interface Builder, so it was okay. But still a pale comparison.
P.S. If you are old enough, you will remember when $MSFT tried to steal Quicktime so its video products didn't suck. They got caught because they copied the machine code. Byte by byte. #howSad
I couldn't agree more, although I wouldn't be quite so hard on the language. It did have some strong points (for example, it was awesome for integrating with MS Office). To this day the GUI builder was the best I've seen. The current Mac stuff is more powerful, maybe, but the VB builder was way more intuitive and discoverable.
Back in those days, I (and many others) would use VB just to build the GUIs for C or C++ programs. It was that good.
was the language even that bad?
12 replies →
VB6 was the only “low code / no code” tool that actually delivered on its promise.
Bill Gates demoing it from 32-years ago.
https://youtu.be/Fh_UDQnboRw?feature=shared
Microsoft Access was way ahead, in my opinion. Especially that it came with a ready database, reports, etc.. and with VB6 you could practically do anything you want with the operating system. It's interesting we have thrown it all for something much more inferior.
3 replies →
That demo is partially faked - if you look at the "plan B" button, it doesn't actually make the UI show some newly changed data, it simply hides the entire window, and shows a different pre-made static window.
Even the "plan A" button code doesn't show the only interesting part of the code - how the UI is actually updated in response to the changed underlying data.
1 reply →
Delphi was even better. In fact, having used both, I hated vb6.
1 reply →
Excel is arguably the most successful low-code tool.
Even non programmers can come up with some crazy stuff in Excel that just works, that will just run on any machine in their company.
1 reply →
I spent a long time doing VB6 and Windows.Forms, the idea that it was meaningfully better than NeXT or Delphi is just wrong.
Minor nit: he is demoing VB 1
You're totally wrong.
The IDEs I was making in VB6 in the 90s I'm making about twice as quick in Visual Studio 2022 in C# with WinForms.
In fact, quicker because I'm getting GPT to write any gnarly code I need -- like I just asked it if it was possible to add a tooltip to a ListBox and it churned out exactly the code I need, something I would have spent a bunch of time figuring out on my own.
In Delphi u didn’t need any code to add a tooltip to a component - just add it as a property in the inspector. U can do it in code if you want, but it’s easy to do since u see the available properties in the inspector.
3 replies →
I never used VS/C#, but can you drop a TDBGrid connected to a TDataset and then just resize autoloaded columns to your taste? Discussing tooltips on a listbox in RADs is like discussing colors of pencils in a hi-tech workshop.
>>Web and mobile development (which I have done all 3) are significantly slower
The above will probably take half a day in web development (assuming an experienced developer), so no, they aren't "totally wrong" at all.
Or even better one: Delphi (if you were into pascal)
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)?
19 replies →
There was also PowerBuilder and other "4GL" tools.
As an old fart, GUI toolkits and building tools are one of those categories of absolutely essential software that gets scrapped and rebuilt (not in a good way) for every platform.
Kind of like IDEs for new languages, to the point of the article. First comes the language and basic CLI tools, and then about ten years later you might have a mature IDE with full language-specific syntax coloring, autocomplete, visual debugging, variable watches, etc.
And these 4GL tools were doing this with BASIC variants (not compiled) atop maybe 200-300 Mhz processors and 16-64MB (not GB, MB) of RAM. It blows my mind that modern OSes have slowdown and stuttering when the amount of CPU, considering multicore, more pipelining, branch prediction, etc, is likely 100x stronger than the the CPUs back then.
The 4GL languages/tools were all closed source and that did not age well. PowerBuilder folded (probably killed by Visual Basic), and then Visual Basic was killed in one of Microsofts platform purges.
They also were tightly coupled with databases in a UI --> DB architecture. As server architectures exploded in complexity beyond that, the 4GL tools couldn't adapt, partly because they were leveraging so much power of SQL under the hood, and the various server and RPC/invocations never offered the same power and flexibility.
But I can hear you .. SQL over the wire? Like send SQL to a backend service so it can be intercepted and injected and all that? Yup, probably part of the problem. Thick clients and direct internal LAN communication is an implicit requirement.
I would really expect there to be some FOSS Python or JS insta-app-maker that's as easy as VB was, but for some reason nobody wants to work on such things.
Open source devs often don't like writing GUIs or documentation, which VB-like environments rely on very heavily.
Commercial devs meanwhile will work on those things, but generally want to host the resulting app on their own cloud for a monthly fee. That's lockin which is scary to people and so outside of platforms where there's no choice (e.g. Apple) they prefer to have a less productive dev environment but more vendor options.
30 years ago devs were much less sensitive to lockin concerns. Open source barely existed so the question was merely which vendor would you choose to get locked in to, not whether you'd do it at all. And fewer people had been burned by projects going off the rails or being abandoned. The VB/Delphi era ended when VB6 suffered execution-by-product-manager and Borland renamed itself to Inprise whilst generally losing the plot (wasting resources on Linux, etc).
Open source stuff tends to have much worse usability, but there are no product managers, no corporate strategies and in the unlikely even that the project decides to radically change direction it can always be forked and collectively maintained for a while. That concern outweighs developer experience.
Also the ecosystem is just way more fragmented these days. In the 90s everyone coded for Windows unless you were doing mainframe stuff, and on Windows there was C++, Delphi and VB. That was pretty much it and they could all interop due to Microsoft's investment in COM. These days you have JS, Python, Ruby, Java, Kotlin, Swift, C#, Rust, Go ... and they barely talk to each other.
Have a look at https://anvil.works -it's a drag and drop web app creator using python for front and backend. It's as close to Delphi for the modern age as I've come across.
1 reply →
There is Gambas: https://en.m.wikipedia.org/wiki/Gambas
It's more that few people want to make and distribute small desktop apps anymore.
2 replies →
i am working on such a thing myself at https://github.com/yazz/yazz. Also there are many other people trying to build something similar
Never really got why Microsoft didn't keep going with that kind of thing. Why don't we have .net properly inside excel instead of VBA?
Money? Internal elitism?
Office Developer Tools exist.
They're trying to steer people away from end-user programming towards using more well-defined, tested, features. I find it patronizing, but, having seen some VBA, understand the reasoning.
Sekhurity.
Can't have user-programmable tools, because they could be used to ship (gasp!) malware, or let users (GASP!) work around policies of their employers' IT staff.
VBA can't really be removed due to the need to support legacy files (especially Excel). For more sophisticated stuff they expect you to use Office Developer Tools or similar now.
Yes, Delphi too. So also tools like Powerbuilder for developing database-heavy apps. There is nothing even remotely close to those tools now.
Windows Forms is pretty much the successor to VB6 and I think is still supported. Still nothing like it on Linux though, even though people say Linux is way better than Windows for software development :/
The subset of GUI software is much much smaller than the greater whole.
I do agree though that any GUI programming on Linux is a pain compared to Linux / Mac. However the proliferation of web based apps, even those running in electron shows how valuable a truely cross platform GUI framework that is easy to use would be.
Google is trying with flutter and dart but last time I used it I felt it was still being iterated on far too quickly, maybe a bit ( maybe even now ) it will be more friendly to use.
VB6 was primitive compared to what Delphi gave us. It had live design time data binding, visual form inheritance etc. VB and VC++ were primitive compared to that. VCL vs MFC? No contest. The API was powerful, fast, great to extend by inheritance, best in class layout management. There were about 8000 third party components at web sites like Delphi Super Page. Half of those were free, rest were affordably priced for commercial use.
Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience, while keeping Object Pascal (built with IDE experience in mind).
I still prefer the GUI building experience in Delphi 6/7 than anything that was produced since then. C#/Winforms is fine, it was designed by the same person - Anders Hejlsberg, but I wanted something native.
It's unbelievable that something modern like Flutter still fails to capture the design convenience of Delphi, from decades ago. Yes, the design markup is great, but I don't even want to look at it most of the time.
The later Swing/SWT editors never came close. Even Qt, which was inspired by it, never provided the component market experience of Delphi, and it was much more bloated in runtimes.
I fell in love with GUI design with Delphi, but otherwise hated it since.
> Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience
A very core aspect of LCL and how Lazarus works (and VCL/Delphi for that matter) is language features like metaclasses, RTTI, properties, etc which allow the framework to register classes, instantiate them at runtime and inspect the class definitions so that serialization/deserialization and IDE features like the object inspector will work. AFAIK neither Go nor Rust have this.
The only language off the top of my head that has it is C# (which isn't surprising considering both Delphi's dialect of Object Pascal and C# were designed by the same person).
Of course there can be language extensions like C++ Builder did for C++ but they'd need to maintain their own compiler (or fork).
Personally i get the impression that Visual Basic and Delphi's language features were added in tandem with the underlying framework (if not deciding first how the framework and IDE features will look like and then deciding on the language features to support those) whereas modern UI stuff are made with whatever the target language has in place.
3 replies →
what aspect of the development speed do you feel is faster? i feel like i can write things like
faster in html than i could in vb6. maybe i'm wrong about that?
you can try it in your url bar: data:text/html,<select name=title><option>Mr.<option>Ms.</select><input name=name><input type=submit>
of course that doesn't give you database integration, but if you just want crud, you can get crud pretty quick out of django's admin
here's a couple of things i've hacked up recently in dhtml which i think wouldn't have been easier in vb6
http://canonical.org/~kragen/sw/dev3/ifs a 2-d iterated function system editor
http://canonical.org/~kragen/sw/dev3/clock a watchlighting clock
Now try to make a layout with that form example that you could free form put anywhere in 2d space and have it flex properly as the window size changes beyond the defaults that html gives you and make the generic B2B SAAS dashboard like Segment, RevenueCat, Mixpanel, Datadog, Sentry, etc. I bet you could make a VB6 / Pascal equivalent much faster than you would be able to with a mobile or web app, especially if they were updated with a decent graph widget set.
Also your two examples are drawing canvas examples, thats a pretty different target that delphi / vb6 have with their GUI toolkits.
8 replies →
Flash and Actionscript did this for the web but then Apple killed Flash.
Maybe in the era of LLM-assisted webdev tools (like teleporthq.io or MS Sketch2Code etc) the LLM will help sidestep API moats and help bring back such low-code IDEs. Or it could backfire and bring about API moats with non-human-accessible APIs (obfuscated binary only).
Apple did not kill Flash. Flash killed Flash.
Adobe claimed that they could get Flash running on the first iPhone if Apple let them.
When Flash finally did come to mobile via Android in 2010, it required 1GB of RAM and a 1Ghz CPU and it still ran badly.
The first iPhone had a 400Mhz CPU and 128MB of RAM. It could barely run Safari. Were you around when the only way that Safari could keep up with your scrolling was by having a checkerboard pattern while waiting on the screen to be redrawn?
Building apps with VB6 was so productive, wish it was that easy to build mac apps these days.
I haven't used it recently on macOS but Lazarus[0] has mac support. I used it some years ago on my iMac.
If you don't mind proprietary languages, there is Xojo[1] which seems to be designed mainly around Mac (it can do Win32 and Linux apps though).
[0] https://www.lazarus-ide.org/
[1] https://www.xojo.com/
I dunno, I worked with Qt5 and Qt6 recently and creating a UI felt pretty fast and smooth to me (Much more so than the last time I did frontend web work anyway)
That said, I've never used VB6 so maybe I'm missing something...
VBA is still used all the time. As long as you have Excel or Outlook you can use it.
If one wants, VB.NET with Windows Forms still does offer a similar experience.
Didn't Microsoft more or less just copy everything from Borland Delphi? They had drag and drop GUI stuff in the early 90s.
No, Delphi came out years after Visual Basic. There was an earlier Turbo Pascal for Windows, but it didn't have visual design features as far as I remember.
2 replies →
I think by overall value it pales in comparison to Delphi. At leas this is my experience.
Would this be similar to the .NET Webforms? That could be done in C# or VB.
The equivalent would be WinForms
I doubt it
I loved TurboPascal. I agree with everything the post argues.
I would like to expand a bit on it being before the Internet was a huge thing.
The manuals that came with TurboPascal were nearly excellent. It included most of what you would need to get started. When you didn't quite understand something, you had to spend time to figure it out and how to do it well. This could be time consuming, but afterwards you gained important knowledge.
Then there were other books to get, there were "coding" magazines, though at the moment I cant remember any TurboPascal specific ones. and if you were lucky you knew one or two other people who were into coding and you could share problems, solutions, hints and tips. and warez.
There were also a lot of BBSs out there. Where you could ask questions, help others, etc.
These days most people if they face a problem, Google it (maybe now ChatGPT it) find someone posted a solution, cut and paste the crappy code, crosses fingers that it works and off you go.
(or pull down libraries without having any idea what in the world it actually does)
At the same time things have gotten a lot more complex . In my TurboPascal days I knew most of the stack. The programming language, the operating system, assembler, a lot of how the CPU worked.
These days understanding javascript, understanding the runtime / compiler etc, before you even get close to the underlying OS, and certainly not down into assembler amd CPU
I'm not sure whether the issue is stack complexity / depth, but there is definitely something in the culture where it's common for docs and how-tos and Q/A to tell you what to do, the steps/commands/etc, but to do little to help you build any kind of relevant domain model.
This isn't exactly new, there's always been documentation like this, but I think the proportions have changed dramatically since even the early 2000s.
One of my vaguely defined theories is that as valuable as automation is, the culture of automation / process has started to diffuse and act as an influence on how we think, in steps & commands rather than models.
Possible that we've always been steps-results / input-output beings, but I wonder.
I recently created some documentation for a process at work where I explained the 'why' for most of the steps and commands. Not in great detail, but just a bit of detail. I thought that it was good as a step-by-step recipe, while also giving context that could help someone in the event that something didn't go according to plan.
I was asked to remove much of the context that I provided, so as not to confuse the reader, and to make it as direct as possible. This is documentation intended for experienced, technical professionals. I think that the revised documentation is less helpful.
5 replies →
Everyone wants a quick fix these days, in all parts of their life.
How to do X in [an hour, a day,one week of lunches, 30 days.] Heal yourself from X in [an hour, a day, one week of lunches, 30 days. ] Eat/Dont eat this get slim in [ one week of lunches, 30 days, 60 days]
A long time ago I studied martial arts (Karate). Our structure went up to the master in Japan. Once you got past the orange belt, the only way to progress was when the master was visiting. the master also decreed that you had to have a belt for min 1 years, in brown 2 years. in black 4 years before you could try to graduate. He said people needed to grow into their skills and mature.
I haven't thought much about that until a few years ago a colleague told me her daughter had just gotten her first black belt. Knowing her child was no more than 12 that seemed odd, but she had studied hard for almost 2 years.
That seemed like some form of fast-food martial arts.
By pure coincidence I met the son of my previous master at a train . I knew him but the last time I saw him he was still a kid. He was Japanese as well but he spoke excellent English. Something his father had no interest in. He had taken over from his father and was now the master. We talked a bit his dad, the clubs. I mentioned this rapid progression that my coworker's daughter had done. He leaned back and laughed a little.
"Ah, we call those dirty white belts"
A little like coding bootcamps I think.
Yes, too many cookbooks, "with solutions and examples", and no one writes good reference manuals any more.
I kind of get it. I think about a problem, and I am solution focused. Furthermore, I want to learn what I need to implement the solution, and usually don't pay attention to other features that are not directly related to my problem.
However, by giving me a cookbook, the documentators are doing me a disservice in two ways: first, they are greatly limiting the amount of solutions I can use. If my problem is not something they already imagined, I need to find another cookbook or read their source code to find out how to solve it.
And second: they are taking away from me the process of learning about the different parts of the system and how to integrate them into a solution by myself.
And the gotchas are endless. I am using FastAPI and the amount of things I have no idea how they work underneath, until something fails, is mind wrecking.
I wish there was some real reference manual of it, not just the autogenerated function signatures and the most minimally useful documentation I have ever seen. So many things make no sense, and I have to second guess the FastAPI designers all the time.
> there is definitely something in the culture where it's common for docs and how-tos and Q/A to tell you what to do, the steps/commands/etc, but to do little to help you build any kind of relevant domain model.
So very true and this is actually my biggest complaint with MSDN nowadays. It's so difficult to built a mental model of what's actually going on, which makes the documentatino difficult if your needs aren't exactly what the documentation is describing.
I don't know when this phenomenon started but it drives me batty.
Manuals in the era were in general pretty good comparing to today’s open source software standard. Microsoft C++ has about 6-7 dictionary sized books as the manual.
Love that era. I’d definitely pay more if say Jetbrain has these kinds of manuals. But it doesn’t make sense nowadays to have printed manuals, not only because of the cost, but because nowadays people don’t need to read books about language specifications.
I do miss books.
For a while I was a contractor at a hush hush place. We had extremely limited internet access and even stronger rules not to use it. No cellphones, no Wi-Fi, no BYOD.
It was like going back to the good old days with books. We were given the opportunity to order books.
I adapted the best of our team but probably only because I am old.
We had one good old fashioned corded phone, which was for internal calls only. It was not hooked up to anything "outside".
We were given a number that our nearest could call in on.
The number should be connected to some semi anonymous front desk somewhere.
It was to be used (only) in an emergency (they emphasized that)
The routine would be that a member security detail would come to notify the relevant person, escort that person to a room with a phone, that the front desk could route the call to. Someone might or might not be listening in.
As far as I know nobody tried it.
I dont know if the routine is still the same now. I would guess that younger developers would have a much harder time adjusting now than back then.
1 reply →
The first Turbo Pascal IDE, with compiler and debugger, ran as a .com file so all the code and data had to fit in a 64KB memory segment.
The article covers some good points, but misses a few extra things that the Turbo Pascal 7.0 IDE included that made it a true powerhouse:
- A full OOP tree to determine parents/traits of descendant objects
- The ability to edit, assemble, and trace through both inline and external assembler code
- A registers window that showed all registers and flags at any stage of runtime
...all while able to run on the first 4.77 MHz 8088 IBM PC, which was long in the tooth by the time TP 7.0 came out. (The OOP tree required a 286 as they only added it to the protected mode IDE.) This made the TP 7.0 IDE a complete development and debugging environment for assembler as well as Pascal.
I never tested it on an XT, but it ran like a dream on my 286. I wouldn't be where I am now without Turbo C++/Turbo Assembler.
> ...all while able to run on the first 4.77 MHz 8088 IBM PC
Eh, more like it walked rather than ran :-P.
I still use it on that hardware for hobby projects, and while I have to wait 60-120 seconds for a compile, it's still more convenient for me than cross-compiling on Windows and then copying the code over.
It's not how well the bear dances, but that the bear dances at all. That said, EMS and a solid-state hard drived do help a little.
1 reply →
> there are a few things that VSCode doesn’t give us.
> The first is that a TUI IDE is excellent for work on remote machines—even better than VSCode. You can SSH into any machine with ease and launch the IDE. Combine it with tmux and you get “full” multitasking.
I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
Because of VS Code's web roots, it can easily run its frontend on your own local computer while running its backend somewhere else. This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server. The operations that do have to be executed remotely, like saving a file for example, are properly asynchronous and don't interrupt your workflow. Everything is just far snappier, even if you're working from home, through a VPN, on barely working WiFi and an ADSL line.
As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
100% agree. Remote VSCode over SSH is great.
The resource consumption on the client doesn't bother me one bit. Any minimally decent laptop can put up with that load, on battery power, for hours.
I would agree with “whatever it takes to make the server install leaner, more portable, etc” just without sacrificing many features.
If the server side doesn't run on FreeBSD that's really too bad. If Microsoft makes it hard to improve by not making those bits open source, that's very unfortunate.
VS Code remote in some cases is better than local.
As the remote can be a docker container, so when I have to do some experiment, I create a container takes 5 min to setup. I than can play around, test dozen packages and configs, once I am comfortable commit last version.
If I want to do some quick testing on project by different team, again a local container is setup in 2-10 mins. Once done delete the container and my local system isn't messed up.
Last is obvious use case if you want to test anything on reasonable large data or GPUs. Create a cloud server, get data run your code, tests. Push data to S3 and done.
vscode's model of server on host is good because of low latency.
It can be a bit heavy in cpu usage depending on plugins though.
I like emacs tramp in theory since it doesn't impose that, but latency suffers.
With correct ssh config it usually works well, but many times I'd prefer lower latency with emacs being on the host.
That's supposedly possible, but I've never gotten it working.
3 replies →
I was doing exactly the same 30 years ago with X Windows and XEmacs.
> This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server
No, you weren't doing this. You were making a round trip to the server when you moved the cursor or selected text.
7 replies →
It's similar in outcome (doing "stuff" remotely), but not the same architecturally.
VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').
With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.
You still had to do a roundtrip for every single click though, right? I don't think X Windows has any kind of client side scripting system.
That's better than SSH for sure, but still not as good as the web model.
20 replies →
Even in 2023 you can get vim to be more powerful than VS Code. But it's that much more difficult.
As the author states, IDEs haven't necessarily gotten a lot better, but imo advanced features have become a lot more accessible.
4 replies →
In the spirit of what the person you are replying to wrote, you really weren't doing the same thing 30 years ago, because X Windows doesn't really have the capabilities vscode has for remote work. X Windows approach is very primitive compared to what vscode does.
https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
https://code.visualstudio.com/docs/remote/remote-overview
1 reply →
> I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
> As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
> I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
Not sure about other languages, but when I use VS Code to develop Rust remotely, it prompts me to install the rust-analyzer extension (which is my preferred LSP server for Rust) to a remote whenever I'm opening a project for the first time. VS Code is able to distinguish between extensions that need to be installed on the same machine as the code (like the LSP server) and extensions that are just making changes to the local UI.
> Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
I use an extension for vim keybindings in VS Code. When connecting to a remote host, the vim plugin still works fine, itand doesn't prompt me to install anything on the remote side, since the changes are synced to the remote host at a much higher level than that (i.e. locally mapping "dd" to "delete this line from this file" and sending that to the remote rather than sending the remote the keystrokes "dd" and having the remote determine how to interpret it).
My understanding follows (I don’t use it but I’ve noticed the processes running on other people’s machines). Corrections welcome.
It’s split into a client (web frontend) and server that’s doing all the work. The server can be run anywhere but it’s effectively a bunch of stuff installed in a docker container. When you start an instance for a project, it creates a container for that instance with all the code folders etc bound in. LSPs are running in that container too.
It’s possible to use your own image as a base (you might have custom deps that make installing the requirements for an LSP hard, for example).
The trick they use here is that there’s some base container/volume that has most of the server stuff downloaded and rest to go. Whether you start a normal instance or from a custom image they do it the same way by just mounting this shared volume and installing what they need to bootstrap the server.
It also appears they create a frontend window per server process too. So the master client process starts, you select a project folder, they create a new server container and a new client window connected to it. The frontend client is local while each server can be anywhere (obviously you could run the client with X if you wanted to further muddy that).
I use that all the time in my hobby tinkering pseudo cloud server on a odroid SBC. It feels like I'm literally on that specific computer directly. Plugins like docker work as well
I've been wanting to try something like that with neovim's remote features, but haven't found the time. Has someone attempted this? If so, how successful was it?
I've always been a big user of powerful laptops because I do like the mobility (allows me to work/browse stuff outside my home office) and I dread the pains of properly synching my files across a laptop and desktop (not only documents/projects, but also configs and whatnot).
`nvim scp://devhost/main.c`
Using the editor on the server from a remote connection is silly. However VSCode is not unique. On my local Emacs I use ssh via tramp [0] to browse files on the server and then edit localy. HOWEVER I also have physical access to my server. Emacs then gives me the added benefit of being able to run in terminal on the physical server without any window manager installed.
[0] https://www.gnu.org/software/tramp/
> Using the editor on the server from a remote connection is silly.
In my experience, this is the best way to do remote work. The alternative is to either not work with remote resources (data, hardware, etc), work locally and sync changes to remote, or work locally with a remote mounted file system (unless you need remote hardware).
For the parent, they needed GPU access, so they had to run remotely for hardware access.
I normally need particular data that is too big to move locally, so I like to work remotely for that reason. I could remotely mount drives via an SSH Fuse mount, however the IO speed for this method can quickly become a problem. For me, it is a much better experience to either use a remote web editor (rstudio server), VSCode remotely (which is a remote web editor over ssh), or vim. With web based remote editors, you still draw the screen locally, but get updates from remote. And more importantly, compiling and building takes place remotely.
I find this method much better than either pure remote access (VNC/RDC/X11) or local-only editing with syncing code and/or data. But it very much depends on your work. When I don’t need to work with remote data, a locally managed Docker devcontainer provides a much better development experience.
13 replies →
I worked at a place that had a half built distributed system that we still needed to use (many bidders buying Ad space from a API based market). one great thing with tramp is that you can tramp into multiple systems simultaneously. So you are editing say files from 5 different systems (tweaking the yaml or whatever) at the same time. You could then start eshells on each of those systems at the same time. It made it really easy to adjust the settings and restart multiple apps really quickly (big screen, 5 files on top, 5 shells on bottom). I always get a kick out of people saying "you use that! you need to switch to editor X it has feature Y!" And me thinking yeah, that feature has been in emacs since before you were born. it is getting a bit crufty in its age though. Its main attraction is for people who like LISP. There a project called lem (IIRC) that is rewriting it in much higher performance Common Lisp.
1 reply →
> Using the editor on the server from a remote connection is silly.
Why?
3 replies →
Tramp is quite slow though, IMHO, and last I used it Emacs very much expects file access to by synchr.
1 reply →
This ability also proves useful when trying to do complex package management in an isolated manner with ROS; I ultimately used a remote vs code shell running off the robots OS to just have my ide recognize the many local and built dependencies that requires a full ROS setup.
I wish I could find a decent way to make VSCode work properly on Android.
People still forget Eclipse when it comes to a full-blown yet not bloated IDE. That thing consumes less than a bare bones VSCode install while running 5x the tools. It can handle everything from code to git to CI/CD and remote development since 2013.
I'm using it for 20 years and I think it's the unsung hero of the IDE world.
This article doesn't mention it either as a modern GUI IDE.
There’s a reason people don’t talk much about Eclipse these days and it’s because it was a pain to maintain back when it really should have shone.
I really wanted to like Eclipse but gave up on it a decade ago because it required constant management from release to release. I remember one job I had where I didn’t need an IDE all that often and I would spend nearly as much time configuring Eclipse again upon the next time I came to use it, as I was spending time writing code in it.
I’m sure it’s improved leaps and bounds in that time - 10 years is a heck of a long time in any industry, let alone IT. But I do know I wasn’t the only one who got frustrated with it. So myself and others switched to other solutions and never looked back.
I was there, but it has changed. "Four updates a year" was a great decision to make, to be honest.
It just updates now, and I export my installation XML and send to people when they want the exact same IDE I use.
> I remember one job I had where I didn’t need an IDE all that often and I would spend nearly as much time configuring Eclipse again upon the next time I came to use it, as I was spending time writing code in it.
So basically the same as setting up and configuring a development environment today, except that nowadays it's a lot more centered around the command line and involves a bunch of disparate, half-documented packages/tools from GitHub (and that also inexplicably require 10 to 1000 times more space and clock cycles).
1 reply →
I used to like Eclipse but honestly it was and still is a hog. At the time i used it in the late 2000s it was basically the best IDE for C++, having features that Visual C++ users either did not have or needed to pay extra for plugin to get. I used it at work then when everyone else used Visual C++.
However at home i had a computer i bought late 2003 (which was a high end PC at the time but still) and the program was so heavy i remember despite running it under a lightweight environment (just X with Window Maker) i had to choose between Firefox and Eclipse because otherwise things would crawl due to the excessive memory use both programs made :-P.
Eventually i switched to other IDEs and forgot about Eclipse. But i did try it recently again and while obviously doesn't feel as heavyweight as it did back then (i'm running it on a 8 core machine with 32GB of RAM so it better be), it still feels sluggish and startup time is still quite slow.
Also TBH i never liked the idea behind workspaces.
These days i don't write C++ much but when i do i use either QtCreator or Kate with the Clangd LSP (which i also use for C).
I think 9 seconds startup time with 1GB of memory use is pretty acceptable for an IDE at the size of Eclipse (just timed).
Considering I'm not closing it down for whole day when I'm using it, waiting for ~10 seconds in the morning is not that bad.
In 2003, Eclipse was at its infancy and was an absolute hog, I agree on that front.
Actually you are not expected to have "n" workspaces. Maybe a couple (personal and office) at most. Project relationships and grouping is handled via "referenced projects".
Kate is an awesome code-aware text editor. I generally write small Go programs with that, but if something gonna be a proper project, it's always developed on Eclipse.
10 replies →
It wasn’t “a hog” it was the hog. I don’t know where OP gets the idea that it was svelte. IntelliJ is considered a pig and a half in most eras but at the time, for most if not quite all projects, Eclipse had a worse memory footprint, for less functionality.
Also the UX was mediocre at best and infuriating at worst. Practically every interaction worth performing in that editor took at least one more click or keystroke than IntelliJ, and I would rank IntelliJ as merely good, but not amazing with input economy.
For about five years, my daily start of the day ritual was starting eclipse, going to a 10 minute standup, and coming back two minutes before it stopped loading. To be fair, it's probably better now, and I stopped doing Java work in 2014.
Anyone who thinks Eclipse is compact is hallucinating.
what I dont understand about java is why doesn't it just take what it needs? If I commanded eclipse to open, that's it. Open an editor, maybe 2-3 recent files, and let me move the cursor around. If IntelliJ isn't ready yet, so be it, but dont slow my UX down because it's running a bunch of services I didn't ask for. If I hit the IntelliJ autocomplete then fine, I'll wait if it's not ready, but until then, the editor frames should be just as snappy as notepad. Java doesn't put the user first!
1 reply →
Interesting. I hate Eclipse with a passion, I find the ergonomics so horrendous, and back in the days it was a hog. Maybe on today's hardware it's leaner than webkit based vscode. But the last time I tried to use git with it .. it made things 10x harder than the CLI. It was so bad that I developped RSI in 24h (and I'm a daily emacs user)
It’s possible that Eclipse has had a “Firefox moment” where someone carved it down to a lighter core, but I’ve no reason to check.
Seconded on the ergonomics. They were a joke. Longest inputs of any IDE I’ve ever used. If your sequences are longer than vim you need to get your head examined.
1 reply →
Sorry, but "not bloated" really doesn't enter my mind when I think of Eclipse. The few times I used it for Java programming, it took forever to start up, and the UI was laggy as hell during regular use. Granted, that was about 10 years ago, but on a (at the time) beefy Windows PC.
But Eclipse was often laggy and slow. So it felt bloated to the users than VS Code which is snappier even though it is bigger
It was, for C++, for a couple of years, 12-13 years ago. It's neither laggy nor slow for the last 8-9 years. I've written my Ph.D. thesis on it, on C++, which was a sizeable high performance code.
It never crashed, allowed me to work remotely if required, integrated with Valgrind, allowed me to do all my tests, target many configurations at once, without shutting it down even once.
Currently it has a great indexer (which is actually an indexer + LSP + static analyzer and more), LSP support if you wish, and tons of features.
It gets a stable release every three months, comes with its own optimized JRE if you don't want to install one on your system, etc.
Plus, it has configuration snapshots, reproducible configurability, configuration sync and one click config import for migrating/transforming other installs.
That thing is a sleeper.
4 replies →
My experience with Eclipse, about 10 to 15 years ago, was the exact opposite. It was incredibly bloated. With some combination of plugins installed, it became unusable. At a previous company, we were using some sort of Scala plugin, and Eclipse couldn't even keep up with my typing! I moved on to IntelliJ around that time.
All of the JetBrains users sitting around comparing notes, trying to figure out what was wrong with our coworkers that they thought eclipse was worth using, let alone defending.
JetBrains has plenty of problems, which they seem to want to address but I fear Fleet won’t fix, and I lament but understand people wanting something lighter these days, but eclipse isn’t even in that conversation.
2 replies →
I (author) wouldn’t say I “forgot” about it. I was there when Eclipse became a thing, and my memories are all pretty grim. Difficult to use, slow, very resource hungry… so I never really paid much attention once I finished school. It probably is better now as others are saying, but I don’t know nor care at this point to be honest.
I started Android development with Eclipse. That IDE is a beast. People also forgot about Netbeans.
Netbeans was my absolute favorite IDE for Java development. After its last release, I honestly felt lost.
I’ve gotten back up to speed via IntelliJ but it still doesn’t feel as effortless as it did in Netbeans. And way less care and feeding than Eclipse.
Sorry, there’s a lot of “feels” in this post but for me, Netbeans was the one Java IDE that I didn’t have to fight with.
6 replies →
I have good memories of Eclipse, from back when I was doing Java. I remember at the time it seemed everyone dissed it, much as it feels like everyone disses Jira now and for the last decade, but I liked it.
I think you are mistaken, Eclipse takes up 3 times the ram VSCode does...I can use VSCode using only 6gig ram even with big projects with native code such as kotlin, java, c, swift, etc..Eclipse will not run on 6 gig ram neither will jetbrains or android studio.
My system monitor says it's using 1.3GBs after warming up, and even forcefully reindexing a big C++ project.
I don't think VSCode will use 400MBs with that amount of code, plus electron, plus all the LSP stuff you run beneath it.
In that state Eclipse will fit into a 6GB system just fine. I'd love to try that at a VM right now, but I don't have the time, unfortunately :)
If memory serves, fully loaded Eclipse would take about 20-25% more memory than IntelliJ, which was itself rightfully called greedy.
At the time most of us felt it was worth the cost of entry for all of the tools you got, which eclipse had a subset of.
Eclipse... not bloated. I can't say I understand those words in that order.
I used it for quite awhile until JetBrains stole my heart, but it was nothing if not bloated, even then.
I still love Eclipse, and you can pry it from my cold, dead hands.
The last couple of years, however, it feels like Eclipse is actively getting worse. And I don't mean that it's lacking features. I mean that every new release seems to break something else.
I tried reporting some bugs, but that required signing some kind of soul-selling agreement with the Eclipse Foundation or some other nonsense.
I then tried fixing those bugs, but there is no up to date documentation on how to build the IDE from the myriad of repositories and modules. So I gave up.
VSCode is really a text editor-in-IDE-clothing. Also, it's an Electron app and those are notoriously resource heavy.
~20 years ago I became an early IntelliJ user. From version 3 maybe? It's hard to recall. I've never looked back.
But I did try Eclipse and... I never got the appeal. For one, the whole "perspectives" thing never gelled with me. I don't want my UI completely changing because now I'm debugging. This is really part of a larger discussion about modal editors (eg vim vs emacs). A lot of people, myself included, do not like modal editors.
But the big issue for Eclipse always was plugins. The term "plugin hell" has been associated with Eclipse for as long as I can recall. Even back in the Subversion days I seem to recall there were 2 major plugins (Subclipse? and another?) that did this and neither was "complete" or fully working.
To me, IntelliJ was just substantially better from day one and I never had to mess around with plugins. I don't like debugging and maintaining my editor, which is a big reason why I never got big into vim or eclipse. I feel like some people enjoy this tinkering and completely underestimate how much time they spend on this.
For me, perspectives are perfect, because it provides me a perfect set of tools for everything I do at that moment. It's probably a personal choice, so I agree and respect your PoV.
The plugin conflicts were way more common in the olden days, that's true, however, I used subclipse during my Master's and it was not incomplete as my memory serves. It allowed me to do the all wizardry Subversion and a managed Redmine installation Assembla had to offer back in the day.
It's much better today, and you can work without changing perspectives if you prefer, so you might give it another shot. No pressure though. :)
Trivia: VSCode Java LSP is an headless Eclipse instance.
1 reply →
I’ve been using vscode for a few years now and while i find its search amazing, it doesn’t do much more for me. Its syntax highlighting is good, but the auto complete recommendations have been driving me insane recently.
Writing rails api with a nextjs ui, anyone got any suggestions on alternative paths i should take?
2 replies →
> VSCode is really a text editor-in-IDE-clothing.
This is kind of my problem with it. I'll use VSCode for typescript but I avoid it if there are other alternatives. The entire model of VSCode just doesn't jive with me.
Eclipse used to be my reference for most-horribly-bloated-IDE....
It's bizarre to now see it described this way.
Eclipse is the first thing that comes to my mind when I think of the most bloated and stodgy IDE on the earth.
Ha. I mostly used Eclipse in college. I learned how to compile programs from the Command Prompt (Windows user back then) primarily to avoid Eclipse LOL. It was dog slow and somewhat difficult to navigate
There does seem to be a lot of hate for eclipse. The complaint I always hear is that it is a pain to use. Personally I’ve always liked it, even though I’ve used the other popular IDEs.
Same here.
You will find old rants from me complaining about workspaces metadata, but that problem has been sorted for quite sometime now.
Agreed. And there's simply nothing that comes close to the power of the workspace when working on multiple projects that share dependencies.
1 reply →
A blast from the past there. I used Eclipse for Java in its infancy while I was at university and thought it was decent enough compared to whatever version on emacs would have been on whatever version of Solaris was on my CS department servers.
A couple of years later I started an internship at a bank and spent ~3 hours trying to get a project building before someone introduced me to IntelliJ, which I still use every day almost 20 years later!
I'm shocked to hear you describe it as "not bloated". Eclipse took many seconds to start up, responded slowly to typing, and used huge amounts of memory. It was by far the slowest of any application I had used. I used it when I had to, but never got comfortable with it because it was just way too slow.
I should fire it up, I haven't tried it in a while. It was the only thing I could use that seem to accurately (more or less) index large projects that you, uh, had some issues compiling and just want to navigate around and look through the code. now I mostly just use rg for big projects, inside of neovim
Eclips also had (have?) The very interesting mylyn plug-in which narrows down the code to the context your working within. Think collapsing everything in eg the project tree and also functions within files.
This context is built up based on what part of the code you work on.
Honestly, I feel like the primary reason why IntelliJ "won" over Eclipse and Netbeans was that it was first to market with a decent-looking dark mode. Back when Eclipse and Netbeans were as stark white as Windows Notepad... and caught with their pants down as developers abruptly decided en masse that white backgrounds were over, and every app needed to be dark mode first.
Hell, Eclipse STILL doesn't really have a nice dark mode. The actual editor view looks okay, but the dark mode feels very bolted-on to the surrounding UI.
I think this is the primary reason why VSCode is eating the world today. People will talk about the plugin ecosystem and all these other community inertia advantages. However, VSCode was exploding in popularity BEFORE that plugin ecosystem was in place! If we're really honest with ourselves, we flocked to because it was even more gorgeous looking than Sublime Edit, and without the nag modal to pay someone 70-something dollars.
Appearances MATTER.
JetBrains “won” because of code inspection tools and code completion that was light years ahead of Eclipse and Netbeans. I remember in my Java days I used to be able to do in a keystroke what my Eclipse friends did in a dozen dialogs.
1 reply →
No, dark mode is a red herring. I used IntelliJ because it had better functionality and wasn't incredibly slow (only somewhat slow).
User experience matters. Most of user experience has nothing to do with dark mode. Dark mode is pure fashion, and should be prioritized appropriately.
I love eclipse, but it's unbearable on macos
How come? I use it regularly. Genuinely asking.
2 replies →
How so? Use it daily, with hundreds of open projects and it just flies.
I’ll raise you NetBeans to that.
> People still forget Eclipse
thank god
For me, the closest modern successors to the Borland suite are Visual Studio (not VSCode) and the Jetbrains IDEs. The feel like they're the only one with a holistic, batteries included, design that actually focuses on debuggability.
I actually feel that the terminal-based focus of modern FAANG-style development actually hindered proper tool development, but I was never able to explain it to anyone that hasn't used Borland C++ or Borland Pascal in the past, except maybe to game developers on Visual Studio.
C++ Builder versus Visual C++ for RAD GUI development.
I never understood why Redmond folks have so hard time thinking of a VB like experience for C++ tooling, like Borland has managed to achieve.
The two attempts at it (C++ in .NET), and C++/CX, always suffered push back from internal teams, including sabotage like C++/WinRT (nowadays in maintainance as they are having fun in Rust/WinRT).
The argument for language extensions, a tired one, doesn't really make sense, as they were Windows only technologies, all compilers have extensions anyway, and WinDev doesn't have any issues coming with extensions all the time for dealing with COM.
Or the beauty of OWL/VCL versus the lowlevel from MFC.
DevDiv vs WinDev. The Windows group maintains the C++ compiler. So you get the resource editor for dialog templates and that’s about it. And that actually got worse from Visual Studio .NET onwards, my guess is that it got took over by the DevDiv people when they unified the IDEs.
1 reply →
out of the loop, how is terminal-based development related to FAANG?
I guess it's caused by the "brogrammer" culture of Silicon Valley, where you would get hazed if you dared using a GUI-based tool. Also, being more focused on open-sourcing their tools (because other companies do not open source them, therefore being un-cool), which begets a "simpler" and "engineeristic" approach to UX, which do not need UI experts and designers.
Lots of companies end up with their own internal tooling. They have their own build systems, packaging systems, release systems, version control, programming languages, configuration languages, everything.
Some even have their own editors.
There is a lot of value in picking a transferrable editor and using that. From that point it becomes "what is the best editor that will _always_ be available". Emacs/Vim fit that.
Then the muscle memory can begin to grow, and there is one less bit of friction in starting a new job.
One of the best pieces of advice I received was "pick an editor and go deep".
1 reply →
It became sort of a hackerish trend in the past decade, usinga hyper customized (neo)vim in lieu of an IDE.
Except maybe Apple, all the others are service-oriented companies. They run heterogenous pieces of code on their servers and their ideology is “move fast and break things”. It’s a hipster culture that reinforced the use of 1980s “video terminal” editors and CLI tooling because they were supposedly more flexible for their workflows.
I loved Turbo Pascal, but to me the high point of Borland's tooling was Delphi (1995). I don't want to sound like old man yells at cloud, but every time someone says that building GUIs with Electron is so easy compared to native apps, I just wished they experienced Delphi in its prime.
There are some very short/simple demos on YouTube:
https://www.youtube.com/watch?v=m_3K_0vjUhk
> but every time someone says that building GUIs with Electron is so easy compared to native apps, I just wished they experienced Delphi in its prime.
Every time someone says that, I mention Lazarus. I stll get a thrill out of using it (one of my github projects is a C library, and the GUI app is in Lazarus, which calls into the API to do everything).
The problem I find with Lazarus is that it seems to be slowly dying; yes, they still work on it, but feature-wise they are very behind what can be done with HTML+CSS and a handful of js utility functions.
A wealthy benefactor could very quickly get Lazarus to the point of doing all the eye-candy extras that HTML+CSS let you do (animated elements, for example).
Looks pretty similar to C# WinForms that ships with Visual Studio. https://youtu.be/n5WneLo6vOY?si=maped85dMX90KIn1
They can still experience it today with the community edition.
If you can agree to their very strange terms and conditions.
Or, use Lazarus/Free Pascal, which is almost identical, except for the documentation, which needs a massive overhaul, in tooling and content.
2 replies →
I will happily fill an hour with trash talking Microsoft, but getting the father of Delphi on board is one of the shrewdest things they’ve managed. I wish he’d found a different project to sink his teeth into though.
Twenty nine years ago, Metrowerks Code Warrior was released https://en.wikipedia.org/wiki/Metrowerks
I had the shirt ( https://www.rustyzipper.com/shop.cfm?viewpartnum=282427-M558... ) and wore it for many years... wish I knew where it was (if its still in one of my boxes somewhere).
The IDE was no where near as clunky as a text only DOS screen. https://www.macintoshrepository.org/577-codewarrior-pro-6
The entire System 7 UI was really a thing of beauty.
The alternative was MPW which was awful! Long Live Code Warrior! Its debugging was probably a decade ahead of its time.
I still miss the simplicity and power of the Lightspeed/THINK IDEs for Pascal and C.
For me Metrowerks was a big step back in terms of complexity, speed and affordances.
The thing that I loved about MPW was MPW Shell and Commando, brilliant if you compare it to the state of the UNIX art at the time, probably tcsh, and still to this day feeling just a bit like the future.
At least the programs in the screenshot have actually useful and visible scrollbars. Seriously, scrollbars are super useful and should never be hidden, they both provide information you want to see and actions you want to do, why is everything trying to make them as subtle as possible today, even most Linux UI's which I'd expect are normally made more for usefulness than "design trends"?
GitHub's Android app doesn't even show scroll bars. And no scroll grab or snapback in apps even when there is a scroll bar. Am I the only person who scrolls back to check something and wants to quickly return to where I was in a document? Even if just FF on Android had this I would be happy.
On desktop we can drag scrollbars but I can't imagine what it's like to use modern 4-8px action area scroll bars if you have fine motor control challenges.
I just don't understand how we got to this point. Do people not use the apps they write?
This must be a bug though. If you unfold hidden comments, you jumpt to the BOTTOM, where you just WERE, rather than the top. So you scroll up, with no scrollbar, frantically, because you don't know how far you have to go. Until you reach the top - and you drag down ONE MORE TIME, because you're scrolling frantically, so the whole thread reloads, and everything is folded again, and you're back where you started.
On Linux this depends on your theme really, all the themes i use have scrollbars - e.g. here is an example with Gtk3 (which IIRC introduced the "autohiding scrollbars" to Linux desktop)[0]. It is "cdetheme-solaris" which i think is from [1]. I might have modified it a bit though. Though normally i use Gtk2 apps with a modified "cleanlooks" theme (a screenshot from Lazarus[2] i made a couple of days ago shows it - including the scrollbars :-P).
[0] https://i.imgur.com/CAyu5Ay.png
[1] https://github.com/josvanr/cde-motif-theme
[2] https://i.imgur.com/Yw1tTcD.png
Moreover, make the scrollbars big enough for my thumbs on my touch screen. Or at least make it optional.
Even if VSCode/other IDE had features that blew Neovim out of the water, I don’t think I’d move over. The customizability, modal aspect, and open-source-ness are huge for me. I can create macros on the fly for repetitive tasks, can navigate without ever having to stall my train of thought to touch my mouse, and customize every single key binding and the code that it runs. I can create custom commands to do every single thing I’ve ever conceived of wanting to do. I can upstream bug fixes and see those others have suggested that haven’t been up streamed yet. I will concede that for some, maybe this is too much work to set up “just a text editor”, but I enjoy it, and I spend most of my day editing or viewing text, so to me, it’s worth it.
If there is one thing I’ve learned in my years of software engineering, it’s that everyone prefers different workflows. Let people build their own, however they want, with whatever tools they want, and they will be happier for it.
Almost everything you wrote is available for any modern IDE, and modern IDEs, thankfully, don't assume that your code is text. So they give all the things you mentioned and superior tools to work with code out of the box: anything from refactoring to code analysis to several types of semantic search to...
Corect me if I'm wrong, but you can't define macros in a couple key strokes or contribute to development of any modern IDE.
Nor they were designed to be hackable or customizable. If you open one of the setting sections in VS-Code you are presented with giant, over-engineered control panel with myriad of options you can toggle.
Where Vim has a blank canvas you splash with couple dozen lines of code to make it unique and personal. It's almost like you aren't using just vim, but your own hand-made editor built on a great minimal base, that is Vim.
4 replies →
I am easily distracted (as in, ADHD-like), I enjoy very sparse work spaces in general. Tools with lots of icons, windows, and other widgets are very uncomfortable to me. I prefer typing commands, I believe a well written command language and a good search function are more comfortable. I will go to great lengths to avoid some tools if it means avoiding a clickodrome : for example, when coding for STM32 devices, I prefer bare metal GCC + makefile over STMCube.
To each his own tho, it's nice to have different tools for different peoples.
The two most indispensable programs for me are "midnight manager" for Linux/OSX and the like, and "Far Manager" on Windows (and mc there too under wsl2).
I'm lost with Far Manager at work. I've stopped using Explorer long time ago (and use it only to verify some reported workflow from other users, or some obscure thing not possible in Far Manager).
Other tools: tig (pager), emacs, mg (mini-emacs) - I wish that was available on Windows too without needing msys2/cygwin, and few others.
Back in the DOS days - it was Norton/Volkov Commander, PC Tools, but also Turbo/Borland Pascal 3, 4, 5; the most awesome E3 editor (from this series - https://en.wikipedia.org/wiki/E_(PC_DOS) ) - and many more
30 years ago, THINK C for the mac was already nearing discontinuation. It was a great compiler plus plus graphical IDE with debugger for its time. Hard to find info about it, but this site has some screenshots of the various versions:
https://winworldpc.com/product/think-c/4x#screenshotPanel
This fella has a number of interesting videos of development on System 6 using THINK C!
https://jcs.org/2022/03/05/serial
Yes! I absolutely lived in Think C for many years. You’re right though, it was on the way out by then, supplanted by CodeWarrior and MPW, which were both really good too.
Visual Studio and XCode are the closest experiences to “first-class IDEs”, reminiscent of the Borland stuff from the early 1990s. They offer tight integration with the native toolchains and a set of menus that mostly make sense. Environments like VSCode or Emacs are a generic platform for text editing and file manipulation, a lowest common denominator for a variety of languages, workflows and tastes.
Try Eclipse, or Geany if you want something very small, yet powerful for its size.
How odd to find a mistake in 30-year-old Turbo C++ man pages from a screenshot. printf and vprintf send send formatted output to stdout of course, not stdin.
Language server protocol has really improved things. I use it with neovim. Makes it straightforward to get IDE features in vim for a variety of languages & allows code analysis part to compete. With Go I'm mixing golangci & gopls. In Rust there was a transition from rls to rust-analyzer. & this effort is able to be shared between vim/vscode/emacs/etc so once someone makes a good lsp implementation it doesn't need to be ported everywhere
I was expecting the author to mention Smalltalk because I distinctly remember people praising Smalltalk for its IDE but I think the IDE I was thinking of is from the late 90s or early 00s.
I think it's fair to say Smalltalk(s) have had in many aspects the most advanced IDE in existence at every moment since its introduction.
Demos for a couple old versions: https://www.youtube.com/watch?v=NqKyHEJe9_w Demo for Pharo: https://www.youtube.com/watch?v=baxtyeFVn3w
Not only Smalltalk, all Xerox PARC Workstations
Interlisp-D, Mesa (XDE) and Mesa/Cedar, all shared same ideas with Smalltalk, regarding developer tooling.
Same on Genera with Lisp Machines.
An interesting continuation of that evolutionary line is the Open Dylan IDE: https://opendylan.org/history/apple-dylan/screenshots/index....; the deconstruction of the object browser / Miller columns seems interesting even as a general UI concept.
> I think the IDE I was thinking of is from the late 90s or early 00s.
Smalltalk's from the 70s and 80s, and almost certainly had what you're thinking about given it's where both Microsoft and Apple got their foundational ideas (restricted to significantly less powerful hardware), and later unrelated smalltalks retained a lot of now quirky considerations and behaviours. Self inherited a lot of those and is from the late 80s.
So yes, I was also expecting the author to talk about Smalltalk.
If you actually look at Xerox’s hardware, it’s quite a stretch to call Lisa or Macintosh “less powerful.” It’s kind of amazing what Xerox was able to accomplish on such underpowered systems; they did it largely by having multitasking microcode to handle performance-sensitive I/O, and implementing BitBlt there too.
I suspect there are quite a few more niche languages/interfaces that the author didn’t consider when it comes to GUI IDEs. I thought of EiffelStudio immediately, myself, having worked with a group that used it in a past life.
I don't think SmallTalk ever had a TUI. Even the very early versions on the Xerox machines used a GUI, and that GUI persisted even when it was all ported to Solaris.
Oberon was this weird mix where you had a proper GUI on thr screen but it would basically only show text. You could run commands by selecting text from inside any arbitrary window. The plan9 OS and Acme editor have kept this workflow.
Digitalk had Smalltalk TUI for DOS named Methods. https://pbs.twimg.com/media/ET8sPbsXQAAcgpb?format=jpg&name=...
The title of the article doesn't mention TUIs (or UIs at all) but I was thinking of a GUI. Specifically it seems I was likely thinking of Pharo (which is '00s not '90s so off by a decade).
1 reply →
Vim is the only tool I've been able to use at every place I've ever worked at, from intern to staff engineer in three FAANG companies. I've watched tool teams spend months integrating the latest GUI editor, only for it to get killed by corporate acquisitions and replaced with N+1 that offers an almost identical feature set.
Meanwhile there's always a community of vim and emacs users who build all the internal integrations by themselves. Vim and Emacs aren't editors, they're platforms and communities, and the benefit of using them over VSCode of JB is that you get to be a part of these communities that attract the best talent, give the best troubleshooting advice, and share advanced configurations for everything and anything you could possibly ever want. They are programmable programming environments first and foremost, and that attracts people who are good at programming and like to hack on stuff.
Technologists who choose the propriety path of least resistance when it comes to their most important tools I think are ultimately missing out in a lot of ways, least of all is the actual editing experience. A craftsman should understand his tools inside and out, and picking something you can't fully disassemble and doesn't have the breath of knowledge a tried and true open source tool ultimately becomes just as frustrating as the initial learning curve of these older tools.
Changing IDE isn't that big of a deal.
I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
If you worked in C++, then visual studio has been around for 20 years - visual C++ for 10 years before that. If you use java, then intellij has been around for 20 years. Pycharm for 15 years. If you're writing JavaScript, I don't know what to say because the framework du hour has changed so many times in that time frame that I don't think the tool saves you much.
> Technologists who choose the propriety path of least resistance when it comes to their most important tools I think are ultimately missing out in a lot of ways, least of all is the actual editing experience
Equally, I can say purists or idealogists are so concerned with theoretical changes and breakages, and so afraid of the possibility of something changing that they miss out on game changing improvements to tooling.
I think the way people use IDEs is a lot deeper than just reducing them down to "purist" or "ideologist". That sounds a tad bit dismissive for something that is essentially your trade tool. It's akin to saying all keyboards are created equal because they have the same keys. The way you lay the thing out and the perspective that you build it for matters quite a lot. Distilled in a quote, "the whole is greater than the sum of the parts."
I got used to JetBrains' key mappings when I was at my last company, I also adored their debugger. My new company uses VSCode and I started down the venture of remapping all of them to JetBrains keys. I ended up with a lot of collisions and things that no longer made sense because the keys were mapped using a different perspective when laying them out. I'm sure I'm not alone being in a pool of engineers that primarily navigate using their keyboard.
VSCode's debugger is better now, but it still doesn't really stand up to JetBrains'. On the other hand, launching VSCode on a remote box is much easier and their configuration is much more portable with their JSON based settings files. I like using VSCode, but it took me months to get up to speed with how I navigated, and more generally operated with, JetBrains' IDEs.
A person using Vim or Emacs has had best in class integration with the unix environment, modal editing, and remote development. Today, both editors have integration with VCS via fugitive or magit, fuzzy finding, LSPs, tree sitter, and code generation tools using LLMs. These tools have not stagnated, they've continued to evolve and stay best in class in many areas. So the "one tool is better than the other" argument doesn't really sway me. My point still stands that the community and open architecture are more important than any one editing feature.
> Equally, I can say purists or idealogists are so concerned with theoretical changes and breakages, and so afraid of the possibility of something changing that they miss out on game changing improvements to tooling.
Blindly following the crowd is also dangerous. Making choices based on principle is what allows good things like open source communities and solutions not swayed by corporations to exist, even though they might require more up front investment.
5 replies →
> I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
I've worked with engineers who studiously avoid configuring any sort of quality of life improvements for their shell, editor, etc. because they claim it makes things easier when they have to use an environment that they can't as easily configure, like sshing into a shared box without a separate user for them to customize. This mindset has always been hard for me to understand; not only does it seem like they're optimizing for the rare case rather than the common one, but it seems like they're actually just lowering the quality of their normal experience in order to make the edge cases feel less bad without actually improving them at all
4 replies →
>I would much rather have to spend a few days to relearn a tool every few years and to get the benefit of that tool, than accept a lower quality tool just to avoid a few days work.
Vim police has issued your red warrants. Justice will be served.
Jokes aside, I'd say yes. I have worked with Eclipse, NetBeans, JB and nowadays I'm happy with VS Code. For a polyglot, it's the best out their at price point $0.0 and tooling is pretty good for me.
I'm doing Python, Go, Typescript and occasional Rust without missing anything.
Few keystrokes faster with command kata would not going to save years of labor. Actuall effort in software engineering is not in typing text or in text editing. Not at all. The battle is far far beyond that and bigger than that.
EDIT: Typos
just to add my $0.02 WebStorm makes writing NodeJS feel a lot more like Java - it's pretty good.
The best part is, you don't need to choose between using IDEs and your favorite text editor! Most modern IDEs with proper plugin support can be configured to provide a superset of Vim's functionality. I personally use IdeaVim on the IntelliJ Platform [1] with AceJump [2] and haven't looked back. You can import many of the settings from your .vimrc and it interoperates fairly well with the IDE features. Although I prefer Vim keybindings and it is technically possible to hack together an IDE-like UX with ctags and LSP, the IDE experience is so much better I wouldn't even consider working on a large Java or Kotlin project from the command line.
[1]: https://plugins.jetbrains.com/plugin/164-ideavim
[2]: https://plugins.jetbrains.com/plugin/7086-acejump
I think you missed the point of my post. The value of Vim/Emacs isn't the modal editing or key chords. It's the community and architecture, which you lose if you're still using JB with a frankenport of Vim on top. In fact, I think what you're suggesting is the worst of both worlds - a reimplementation of Vim on top of an already resource hungry and complicated IDE that's supposed to let you do things with a mouse. So you're left guessing whether something from real Vim will be the same in your Vim, plus you now have two competing environments for ways to do things, and you have to wait for JB to implement features that (neo)vim have already implemented, without supporting the opens source communities that did the work in the first place.
You also lose the killer feature of Vim, which is being able to work over an SSH connection on any sort of device, even those that don't have a GUI.
15 replies →
> that attract the best talent
I've seen hugely talented folk on vim/emacs/emacs+evil, and on VSCode/JB. I think was the latter tools do, it make some of the advantages of being proficient in vim/emacs/regex available with less learning curve.
Currently there are some combinations that simply best-in-class: VSCode+TS, JetBrainsIDEA+Java/Kotlin, VisualStudio+MicrosoftGuiStuff. vim/emacs may come a long way in these areas, but cannot beat the integration level offered in these combinations.
Also, you mention "proprietary", but JetBrainsIDEA and VSC are opensource to some extend, which does improve community imho. But, the fact that they are less "open access innovation" projects, and more company owned is clear to everyone.
Finally: AI will come to software devt, and I wonder if AI tools will ever be available on true open access innovated IDEs.
> I've seen hugely talented folk on vim/emacs/emacs+evil, and on VSCode/JB. I think was the latter tools do, it make some of the advantages of being proficient in vim/emacs/regex available with less learning curve.
Take Reddit and Hacker News as a fitting analogy, a community with a higher barrier to entry/more niche will be smaller, but the quality is vastly improved. There's still going to be people who sit in both communities, and smart people in both, but it's not controversial to say that an initial learning curve tends to attract people who can pass the learning curve and are motivated to do so. Another great example is the linux kernel development process.
> Currently there are some combinations that simply best-in-class: VSCode+TS, JetBrainsIDEA+Java/Kotlin, VisualStudio+MicrosoftGuiStuff. vim/emacs may come a long way in these areas, but cannot beat the integration level offered in these combinations.
Integration in some ways, in other ways a terminal based tool that adheres to the unix philosophy is more integrated with thousands of tools than an IDE where every tool has to be converted into a bespoke series of menu items. Just look at fzf, git, rg, etc. integrations in Vim. They are only lightly wrapped and so the full power of the tool shines through, and it's easy to customize it to your specific needs, or add more tools.
> Finally: AI will come to software devt, and I wonder if AI tools will ever be available on true open access innovated IDEs.
In the same vein, AI tools that act as black boxes and are integrated in the same transparent way as git or rg in Vim at least allow the editor to remain full transparent to the end user, and leave the complexity in the LSP or bespoke tool. I really see no difference between how AI tools will relate to editing as LSPs do today.
1 reply →
> VSCode+TS, JetBrainsIDEA+Java/Kotlin, VisualStudio+MicrosoftGuiStuff
Do any of these finally have something remotely as good as Magit? Or a good email client?
2 replies →
Er.... "VSCode+TS" ... wat?
ITT: people who have not used tools they're talking about with confidence.
Everything available in VSCode is available in (neo)vim, without a slow buggy UI, modals, misfocused elements, and crashes.
All the LSPs used by vscode are easily available, including copiolt, full intellisense, and full LSP-backed code refactors/formats/etc.
5 replies →
In my anecdotal experience the best developers are the ones that don't overly focus on their tools at all. One of the most proficient developers I've known was perfectly ok programming on a little square monitor with Visual Studio where the code window was 40% of the screen real estate.
It doesn't have to be that extreme but it reminds of hobby craftsman who focus on having a garage full of the tools of the trade while never finding the time to work on a project with them.
At some point in a developer career one shifts from a tool focus to a work focus.
I used to be picky about my operating system and often would spend time making the tools that I wanted or preferred to use work within the project dev environment, as opposed to just using the tools my employer provided. It usually ends up just being easier, and if everyone is using the same tools then pair programming or collaborating becomes easier, too, as compared to having to deal with the one stubborn dev who insists on using Emacs on a Mac when everyone else is using Visual Studio.
1 reply →
This has been my experience as well. The most productive people are the ones who actually focus on the work instead of wasting time configuring a perfect editor.
Mileage varies, even the most ardent vim user I know gave up and switched to VS Code this year. It's just too much to try to keep up with when projects and technologies change. I've programmed in C++, Go, Python, Java, and Angular just in the last year. I can believe that there's vim plugins to handle all those, but the energy it would take to find auto-complete and navigation and formatting and debugging and any number of other out-of-the-box IDE functionality is more than I'd like to thing about. Then there's the associated tools - Kubernetes yamls, swagger, markup, Makefiles. In IDEs they are only one plugin download away.
I love vim, I used it exclusively for years when I was doing C/C++. I still ssh into servers a lot and use it pretty much daily. Still, I'm far to lazy to try to turn it into my full time development environment .
> I can believe that there's vim plugins to handle all those, but the energy it would take to find auto-complete and navigation and formatting and debugging and any number of other out-of-the-box IDE functionality is more than I'd like to thing about.
Well, I'll be the bearer of the good news, then!
NeoVim has a native LSP client which unifies all auto-complete/navigation/formatting into a single plugin, only requiring you to install per-language LSP server.
As for debugging, there's also DSP (Debug Server Protocol) which NeoVim doesn't have native support for, but there's a plugin for that.
4 replies →
VSCode is a significantly more pleasurable experience working over a 100ms+ network connection than either vim or emacs (this being the reason why I switched away from emacs/tramp myself).
If you haven’t already, and I know this doesn’t hold up for GUI emacs or vim, but consider running them through https://mosh.org/
1 reply →
Visual Studio Code is currently where all of the tooling effort is focused. For the best tools with the best integration you should be using it or, depending on language, JetBrains. These are easy to use and developers can be productive in them from the word go -- without extensive customization. Hell, if you open a file in a new programming language, VSCode will suggest plugins to install.
You do NOT want to build integrations by yourself. You want to build whatever product you're building. The fact that vim and emacs users do this is yak-shaving that pulls precious time away from the task at hand and serves as a distraction for editor fetishists. Do not become an editor fetishist. Modern IDEs help you become more productive faster and give you more support for things like debugging. (You are using a debugger to inspect and analyze your code, right?)
the ide is not more complicated than your customized Vim setup once you get it close to functionality (you won't). I use all keybindings anyway, so it's not like the UI adds anything bad?
I switched from lightweight editors to IDEs many years ago and my productivity went up A BUNCH - even if sometimes it uses gigabytes of ram. so what? Even my old used machines have 8-16gb of memory now.
I would honestly much rather hire people that work in IDEs than people that like to "hack" on their vi/vim/emacs setup. The number of times I've been in a screen share with someone while they're trying to code or debug something with Vim etc, it just feels so slow to watch them work that I get that embarrassed-for-them feeling.
>"Technologists who choose the propriety path of least resistance when it comes to their most important tools I think are ultimately missing out in a lot of ways"
Nope. Not missing Vim. Live and let live
One nice side effect of modern TUI applications is that they can be distributed via Docker Hub as platform-agnostic applications that just require a compatible color terminal.
E.g. here's my C64 emulator running in Docker (it's a real C64 emulator underneath, but only renders the C64 PETSCII buffer via ncurses, e.g. no graphics or audio output):
...code is here: https://github.com/floooh/docker-c64
Yes, the Borland TUI was pretty good. But nothing came even close to what we had on the Commodore 64 with the X-Ass Dev Kit. You could code in a nice TUI with syntax highlighting. Press a key to assemble in a split second, execute the program, press reset and be back in the TUI exactly where you left off. And this with source file > 64 kByte, creating executables that occupied the complete memory space of the computer.
https://csdb.dk/release/?id=27625
http://www.fairlight.to/docs/text/xass_docs.htm
So productive and easy to use.
Well, I guess we are lacking any LISP or Smaltalk fans to one-up that today :)
This article completely ignores the Macintosh and the greatest IDE ever, which came out in in the mid-80s: Coral Common Lisp. It ran on a Mac Plus with 1MB of RAM and it was fucking awesome. It included a drag-and-drop interface builder that let you build a complete app in literally a matter of minutes. Nothing I've seen has come close since.
That sounds like something I would enjoy playing with? But I can’t find much about it online.
The descendant of CCL runs on modern Intel Macs. (It also runs on Linux and Windows but without the IDE.) The modern IDE is quite a bit different from the original. In particular, it no longer has the interface builder. But it's still pretty good. It is now called Clozure Common Lisp (so the acronym is still CCL) and you can find it here:
https://ccl.clozure.com/
If you want to run the original that is a bit of a challenge, but still possible. The original was never ported directly to OS X so you have to run it either on old hardware or an emulator running some version of the original MacOS, or on an older Mac running Rosetta 1. In the latter case you will want to look for something called RMCL. Also be aware that Coral Common Lisp was renamed Macintosh Common Lisp (i.e. MCL) before it became Clozure Common Lisp (CCL again).
This looks like it might be a promising place to start:
https://github.com/binghe/mcl
If you need more help try this mailing list:
https://lists.clozure.com/mailman/listinfo/openmcl-devel
Good luck!
NeXT had a terrific IDE 30 years ago, called Interface Builder. More info: https://arstechnica.com/gadgets/2012/12/the-legacy-of-next-l...
The IDE was Project Builder, Interface Builder was a separate, as the name implies, builder for interfaces that could then be connected to Obj-C code in Project Builder. They continued as separate apps even after Apple bought NeXT and shipped Mac OS X, until they unified the two into Xcode.
Ah, this takes me back.
Turbo Pascal and Turbo Prolog - those were the days. Borland had the greatest products, and the accompanying books were always well written, used beautiful fonts, and, not less important, smelled nice.
If my memory serves me right, Borland even released their Text User Interface (TUI) library for developers to use in their own applications.
Fond memories indeed!
Loved the concluding question. "So the question I want to part with is: have we advanced much in 30 years?"
Every time I see all the bloated software we are putting out. Is it really worth it?
One program that does it all vs many programs that do one thing really well. Oh, maybe someone should write about this concept, it maybe interesting to ponder :)
30 years ago, I used Trash'em One on the Amiga. It was a text editor, 68000 assembler, debugger and memory monitor in one. I preferred it over its predecessor Asm One (which had been based on Seka), but I don't remember what feature it was that made me switch.
https://www.pouet.net/prod.php?which=92408
You can run Asm One in the browser here: https://archive.org/details/ASM-One_v1.02_1991_Gram_Data
Lives on in the form of asmtwo (lightweight, supports 1.3) and asmpro (featureful, needs v37).
Thirty years ago is 1993, and I was a junior dev using CodeCenter on SunOS. It was a nice editor/debugger with a C interpreter mode that iirc let you inspect aa variable's history and un-execute lines of code.
A few years later I was using SparcWorks on Solaris. When I realised you could pause on a breakpoint and hover the cursor over a variable in the editor to see its value, my brain nearly fell on the floor.
A few years after that I moved to PC development using Visual C++, and then Visual Studio 97 on NT4. Drag and drop UI builders for Windows and Web.
And 30+ years later I still spend a significant part of my working day in VS.
Somehow those text based IDEs of 30 years ago feel special to me, maybe reminding me of a simpler time when there were not too many things to master
I love the aesthetic of Borland Turbo TUIs. I went back and tried to use TurboVision some time last year. It was not good, to say the least. Would be pretty cool if VSCode were themable to the extent that WinAmp was, so we could reclaim that old style.
Is Doom Emacs really 500 MB? How did the author determine that?
I use vanilla Emacs and I believe it was closer to 100 MB when I installed it.
Related: I’ve spent a lot of time trying to find a development setup that runs on low-end hardware (as a reaction to modern bloat, and also as a way to minimize distractions). It has many flaws, but Emacs with Common Lisp is my current sweet spot of “price” (resource requirements) to “performance” (features+speed).
I spent countless hours in Borland Pascal and Borland C as a kid. This brings back nice memories.
We used Turbo Pascal and Turbo C++ for my high school classes, and I have very fond memories of both. This must have been on Windows.
Borland really had a series of these fantastic products, it's a shame they are no more. The only modern company in this space is JetBrains, it seems, so the niche is small.
Turbo Pascal and Turbo C++ are still used to this day in some high schools and even college intro courses. Of course nowadays you need Dosbox to run them on modern computers.
Installer for Delphi 1 looked like this: https://delphicodemonkey.blogspot.com/2012/06/delphi-10-inst...
30 years ago people were using Interface Builder already. Admittedly not that many, but the drag and drop interface is still there integrated into Xcode.
They were, and had it not been for Apple's reverse acquisition, it wouldn't be there in Xcode today.
My graduation thesis was porting a visualization particles engine from NeXTSTEP/Objective-C/OpenGL into Windows/Visual C++/OpenGL, as the department was seeing the end of NeXT and they wanted to keep the research going on.
My supervisor had a NeXT Cube getting dust on the office corner, waiting to be collected.
I found myself lack of energy and time stepping into my 40s and vowed never to waste time “learning” cool editors such as Vim and Emacs.
VSCode is now my one stop editor of choice on Linux and VS on Windows. I also use Jetbrain editors for work.
I’m done. For people like me, who write SQL and Python for data pipelines, the Jetbrain IDEs are no-brainers. We don’t actually get the time or energy to do a lot of side projects so it doesn’t make sense to learn advanced editors such as Vim and Emacs: 1) These two need a lot of muscle memory just to start using it, but we don’t use it on a daily basis, 2) I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
Funny because I entirely agree with you, even though I do the exact opposite. Everything I write is in vim because I'm too lazy to learn an IDE which may or may not still be around in 5 years. I use 0 plugin and 6 lines of .vimrc config which I know by heart, so I don't care if I'm using it locally or remote, I can always get started in 1 minute.
I tried to install plugins but there is always something that fails somehow. Nvim distributions don't install and run out of the box for the most part, I get weird errors regarding lua or something and just give up. As for VSCode I wrote my first python project using it a couple weeks ago (I'm not a developper) and it's alright but a few things annoy me, like the integrated terminal and some things getting in my way.
At the end of the day, each of us should chose whatever we feel comfortable with. I spent maybe 2 hours in my life learning vim movers and never looked back. I don't even use tmux or anything, just open 1 or 2 terminal windows and alt+tab between them, with the occasional :split or :vsplit command.
There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.. you still have to invest and devest everytime a new wave comes. Meanwhile emacs is still mostly emacs. I understand the dread emacs can impose on you, from old keybinding cultures and elisp but there's something timeless and freeing in emacs.
23 replies →
> I use 0 plugin and 6 lines of .vimrc config…
What are the six lines in your .vimrc?
2 replies →
I'm in my late 30s. So maybe not so far away from the age of lack of energy :P
I like JetBrains a lot. Things work seemlessly and easily integrate with external tools that make up the whole experience. But from 2012, I tried to rely as much on shortcuts as possible, for one simple reason, the mouse.
There is no problem with using the mouse. But everytime I have to use while focusing and coding, I find that that small gesture to move my hand from the keyboard to the mouse a bit flow breaking.
I have to move to the mouse, do a thing or two, then find my way back to the J key notch.
I like what NeoVim and emacs bring with regards to the reliance on the mouse. They allow for maintaining the same posture most of the time and focus only on typing.
I dislike how brutal they are at learning how to use them to full potential, and that making them into IDEs takes ages of IDE building rather than project coding.
I like Helix. Which takes a lot of inspiration from Vim/NeoVim/Emacs. But require no configuration to get you going right away. The documentation is easy to read, as of now there is no plugin system but there is a builtin integration with a lot of LSP servers for most of the popular languages by default.
Keys and navigation is easy, it even shows a helper popup to show you which key to use next.
My suggestion is, if you ever want to start a new silly project, and you're feeling free to take it slow for 2 days. Try using Helix on said project.
PS: Helix isn't fully complete by any means, but it really is capable of doing everything you want in many projects without being a hindrence if you can adapt to the lack of some built-in features like git and file tree. Its annoying but I am less upset about it and use alternatives
You can use a VIM plugin for many IDEs, including IntelliJ.
5 replies →
Honest question: are other jetbrains IDEs "feel" similar to the Android Studio one that can be downloaded for free?
I installed it a couple of weeks ago to modify some android app, and boy it gave me vibes of the old Eclipse : sluggish Java feel , with "stuff" happening all around and being slow to render basic editor stuff.
2 replies →
I wouldn't consider myself a vim user, but learned the basic keybindings awhile back (IMO modal editing is the correct way to edit). Knowing those makes it much easier to bounce between IDEs. Sometimes I don't realize if I'm in VSCode or IntelliJ (especially the new UI) until I try to run something.
> I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
I've worked with good programmers who literally hunt and peck. It drove me nuts, but as most will agree, typing is rarely the bottleneck when programming. I've also worked with people who I would consider vim power users, and while they were faster at typing out some tasks than I am, I found they were often typing/moving around the file as their method of thinking. Whereas I might reach for the mouse and scroll around instead. Again, typing speed is rarely the bottleneck.
I'm a heavy Vim user but I agree with your sentiment. I learned Vim during some down time in my first job out of college. It is a great skill to have in my opinion. It helps me complete complicated text editing quickly and easily, especially operations that I otherwise would never have attempted without it, but I never would have had the time or energy to learn it later in my career. I don't think learning Vim or Emacs is a waste of time but I can see how it is definitely not a priority when you have so many other things to do and little time to do them.
I am a life-long vim-er and I only use probably 30% of its features and thats ok. I learn new things all the time, sometimes adding them to my repertoire, sometimes not. There's so much time that can be wasted if you mess around with configuring tools but either fail to remember to use them or fail to get them set up. I wanted to set up ctags and tried a few times, but fell short of memorizing the forward-back shortcuts and got frustrated at the delay when it goes off scanning my HDD instead of the local code 1-2 directories away. so I just gave up.
For me, cool editors are vscode and jetbrains. I've tried to make them my default editors many times but always go back to vim (which I've been using for decades).
I agree that since you are well versed in Vim, it doesn’t make sense to switch unless for something vastly better —- which I don’t see in any existing product.
I have tried to use VSCode more, but, the original emacs keyboard movement is burned into muscle memory. VSCode has a keyboard mapping for emacs, but, its does not feel right. At the end of the day, who cares? Its just a tool, whatever works.
Likewise. I'm 46, and started my career in the late 90s using mostly light editors on Windows (Homesite, etc). Along the way, I've tried a few times to really dive into vim, but just couldn't see the advantage over editors like VS Code, Sublime, Atom, or some of the editors popular before then like Eclipse. However, I do feel comfortable enough in it that I can edit files on servers/containers, which is something I feel is useful for everyone.
I started with emacs. I love the buffer / windowing system and the on-the-fly macros. Also being able to do everything with the keyboard.
But the time spent getting multimode up or good autocomplete when you can simply fire up something like jetbrains IDE, having most of your ecosystem tools integrated the second you launch it makes the decision to switch easy.
Also, dev machine tend to have a lot of resource nowadays so the RAM hungry IDEs are not a problem.
VSCode has solved so many problems for me. The only time I step out of it is when I run into something that might be a configuration issue. For instance, if I’m programming an Arduino, and it’s not working, it’s worth hoping over to the official Arduino IDE to make sure that the “supported” way doesn’t work as well.
Otherwise, VSCode solves almost all my problems, and virtually all my key-bindings are identical.
wow, i had the same experience. reaching my 40s and decided to drop all the cool kids stuff. i used to have emacs/scheme evangelist phases in my life, now i do all my coding using enterprise languages and tools.
i have never been so productive.
VSCode and JetBrains are better overall, but many of the good editing features of Vim are available via their respective Vim emulation plugins. It is still worth it to learn and use Vim mode for efficiency (in my opinion).
they're really not that difficult, its not a badge of honor to use them. I used xemacs and liked it ages ago, and I still use raw vim for quick edits or views occasionally. The reality is modern ides are simply better for 99.99% of use cases. I might not use idea for open log files that are massive, and that's about it.
Same here. Jetbrains and VS Code.
I felt the same way about, atom, pulsar, vscode and whatever comes next.
These editors are going to be replaced and emacs and vim will be kicking.
Brief by underwear was by far my favorite in the DOS days. It ran great on the 286 I had at the time.
IIRC, something like it was ported to Linux in the mid 90s for purchasing. But Linux had vi and Emacs so I do not know how successful that was.
I remember a version named "dBrief", for those of us programming dBase/Clipper code. It was a great tool back then.
Oddly enough, I never used them at the time. It was the CLI compilers, and makefiles. Possibly because most of the work I was doing was cross compilation for embedded systems, not targeting DOS nor Windows. However it was often using Borland/Turbo C and/or Metaware High C, both as DOS based compilers. Occasional y some assembly, or (DOS based) cross compilers for other CPUs (8051, Z80, etc).
Possibly the experience was different for folks not predominantly doing cross system development.
So the editor was usually BRIEF, which could be set up with per file type "compile", rules. Being a multi-file editor, one could "compile" the makefile, hence build the complete system. This would then run the compiler, and jump to the first error; plus commands available to jump to the next error in sequence.
On the occasions I needed something better for search and replace, I'd use a DOS version of vi.
When working on a local (DOS based) tool, one would occasionally have a TSR version of a help manual available, but generally the printed manuals the products came with were preferable.
As to a retrograde step when switching to unix/linux/bsd based development, not really. The combination of Job Control to switch between suspending the editor and running the compiler, together with virtual terminals where one could have man pages open covered most bases.
Not mentioned in the article is JetBrains CLion. Best C/C++ IDE to come along in decades.
https://www.jetbrains.com/clion/
The Borland IDEs really were the swiss army machine guns of their time.
Turbo Pascal was one of the first languages I learned -- never really used it again, but looking back, it was an excellent beginner language.
Back then BRIEF was also an amazing development environment. Now it was not so much an IDE and more of a programming editor, but it was still amazingly good for software development.
I'm surprised there's no mention of QBasic that shipped with MS-DOS >= 5.0. This was built on top of EDIT.COM, and while it only ran a BASIC interpreter instead of compiling an executable like full-blown QuickBasic.
IIRC it had a rather extensive help lookup system for functions, data types, reference tables, error codes, and whatnot. You could step through your program, set debug points, all without exiting to DOS. It was my first ever exposure to an IDE, I thought it was pretty nice for what it was.
I loved QBasic. That integrated help system also came with extensive sample code for each function, including some full programs. Copying and modifying those was a huge boost to learning how to program.
(The article does mention QBasic, though.)
Those Borland IDEs, a show of hands for Turbo Basic as well, were the main reason why I never liked the UNIX development experience, until a professor showed us XEmacs, at the time much more feature rich than Emacs, and vi was still vi, not vim.
Thankfully with KDevelop, Smalltalk, and when Java started to make IDEs more common on UNIX, I no longer needed XEmacs.
Ironically for all IDE-haters, even James Gosling, inventor of XEmacs, says people are missing out not using IDEs, he surely moved on from Emacs ecosystem.
Nit: James Gosling implemented Unipress Emacs aka. Gosmacs, not XEmacs (with a lot of licensing sturm-und-drang). XEmacs was forked from Gnu Emacs at Lucid, by jwz (Jamie Zawinski)
For the comparison:
Interview with an Emacs enthusiast https://m.youtube.com/watch?v=urcL86UpqZc
Emacs actually supports drop-down menus in text mode, with a different key shortcut: https://www.gnu.org/software/emacs/manual/html_node/emacs/Me... There is also a special incantation for proper mouse support in the terminal, because the default is to keep the default handling as copy/paste: https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...
Screenshots using 80x50 mode would be nice, which I remember using in the early 90s.
Did not see mention of Symbolics Genera, a vastly better IDE than any of the ones pictured in this article. And it was quite mature 30 years ago.
There’s a ton of editors that are all roughly equivalent for writing C++ code. Vim, EMacs, VSCode, 10x, whatever.
But Visual Studio is still hands down the best C++ debugger. And nothing else even comes close. Which is a real travesty.
RemedyBG is making progress. But it needs a NatVis equivalent and it needs to be way more reliable. It fails on major projects with obnoxious regularity.
One thing these IDEs had was an integrated debugger.
It seems Unix/Linux really got a nice integrated debugger with ann IDE and gdb is powerful, it is very cumbersome. Hence, it seems there is a lot more printf debugging on Unix, and less use of debuggers than say on Windows where Visual C++ and Borland Turbo C++ both had very easy to use debugging integrated into the IDE.
Commercial UNIXes had nice graphical debuggers like dbx on HP-UX, while Solaris and NeXTSTEP had good IDEs.
Linux eventually got DDD.
Unknown to most is that gdb has a TUI, and is highly scriptable in Python.
Agreed, for the most part debugging has gone backwards (aside from Xcode, Visual Studio 20xx) and was always pretty bad on UNIX. Still amazes me that there isn't a really nice, batteries included TUI debugger (e.g Periscope!).
Did a lot of programming without an IDE. Then some years ago, tried an IDE: Opened a project. Looked at the resulting directory (folder) and saw ~50 files with what I knew nothing -- hadn't even started the work yet.
Got rid of the IDE and returned to my favorite tools and the software I was writing.
My favorite tools work fine, and in particular in the directory I'm in I actually know what each file there is, what it is for, what is in it, where it came from, etc.
In my work, I need to do some programming, that is, software development. So, I do it.
Difficulties are nearly all from poor documentation of other software I need to use. The parts of the programming that are really mine are like cooking lunch -- no problems for my part, but if the pepperoni is not good, that's a problem. To me, programming is, define some variables to store the data, have expressions to manipulate the data, If-Then-Else, Do-While, call-return, input, output, and that's about it.
I do wonder what the easiest, most straightforward path to a full TUI IDE would be today. Perhaps starting from the codebase of a lean graphical IDE like Lapce and adding a TUI-powered backend. (Note that text editors do exist with that kind of interface, the real gap is wrt. the IDE features including LSP and DAP interop.)
One could always use the updated Turbo Vision library[1], which originally was used for the Turbo Pascal/Turbo C++ IDEs mentioned in the article...
[1]: https://github.com/magiblot/tvision
Vim and emacs do already have plugins for LSP. Probably DAP too. But like everything CLI, it might take a bit of initial set up to get it right.
A discussion of editors/IDEs from 30 years ago and the author doesn't mention Brief?
Does anyone here feel kind of trapped by their IDE now?
PHPStorm + Laravel Idea + the laravel-ide-helper package provides such a great PHP/Laravel development experience that I haven't been able to replicate in VS Code or Sublime. But chowing as much RAM as it does, it feels sluggish. Or at least, not as snappy as the alternatives. But I just haven't been able to find a middle ground with the lighter alternatives.
Running the IDE as a thin client with Jetbrains Gateway sounds like a decent solution, if your backend server is close enough for latency to feel okay. From a ~4GB PHPStorm usage, PHPStorm-via-Gateway on GitPod was 1.2GB max.
Perhaps consider better hardware, not some cheap chromebook. 4GB RAM is very little usage for advanced IDE.
M1 MBP.
At the lower tier with the 8GB RAM, it's the most affordable device that will outlast power cuts that are frequent where I am - cheaper than getting a backup power solution. Getting more RAM is a ridiculous cash grab by Apple.
It's a rock and a hard place.
>4GB RAM is very little usage for advanced IDE
Java is awful with RAM in general. Decent text editor plugin setups can get close to the Jetbrains suite for what I do, but it's just a few small UX & plugin papercuts that make the difference. And I heavily doubt that those tools I prefer are that heavy compared to other editors.
1 reply →
Interesting mention of Sidekick Plus, there was a complete SDK for it which I don't think ever got released anywhere (I had a copy as I was working for Borland at the time). It allowed multiple documents to be open at the same time.
It allowed to copy text from screen and paste into its editor, had a modem terminal app, contact app and a calculator. It was a joy to use!
> MS-DOS shipped with a TUI text editor since version 5 (1981)
MS-DOS 5 came out in 1991, not 1981.
In the early 2000s, back in my homeland, high schools were still stuck using Turbo C for programming classes. This was mainly because there weren't many free and lightweight C IDE options available for Windows (I know Turbo C is not a free software technically).
While Dev-C emerged as a possible alternative for console programs and programming contests, it wasn't enough for developing native Windows GUI applications without shelling out for Visual Studio.
This limitation ultimately led me and some friends to explore development on alternative platforms like OS X and Linux. Ironically, even to this day, none of us mastered the WIN32 API.
In the late 90s I used notepad. Mostly writing plain html. Then in the early, 2k I wrote php in Crimson. http://www.crimsoneditor.com/
When switching to mac in 2009, I used Smultron. https://www.peterborgapps.com/smultron/
Followed by sublime text. Then when I started writing typescript in 2016 or so, I switched to vscode.
Fond memories learning both Pascal and C when at high school with 486 Compaq machines and the Turbo compilers.
Not long ago I configured DOSemu with Turbo C to do some bare bones graphics development but I just couldn't get used to it.
Does anyone know or recommend a setup where coding takes place outside DOSemu but yet the compiling/execution takes place in DOSemu? (I mean calling all the build chain outside DOSEmu).
I've seen in an older HN post that someone setup a retro IDE with VSCode but I'd like something more Vim like instead of this behemoth.
I agree with the article. Turbo Pascal was terrific. There is some kind of psychological thing that has me using neovim in a terminal all the time for many years.
I guess it's convenient for ssh. But I miss the affordances of Borland IDEs. Even last night I was working on a web application and was tempted to add a menu at the top of the page, remembering how useful they were back in Turbo Pascal and such.
I did a Google search and found this https://github.com/skywind3000/vim-quickui
Turbo C/C++ was my first IDE, when you know all short cuts, it was quite fast. Then came DJGPP with RHIDE...and for many years, IMHO, Visual Studio 6 was best for kid ( and window user ) like me.
I was a TA in an "Intro to Compute Science" class in the naughts, and using Borland C was quite popular among students who were on Windows.
I never heard a single student complain about the IDE, even though most of them were used to GUI apps only. It was very intuitive and convenient to use. I wish we had nicer TUI tools today - I often miss them when I work remotely over a thin connection passing through a couple of proxies/gateways/etc which have trouble with X or VNC traffic.
My favorite part of late 80s early 90s C/C++ dev was the shitty auxiliary monitor used as a dedicated debugger screen. I swear I STILL find situations where I want that back.
Separate computer talking to SoftICE over serial port.
I was always kinda partial to the Borland IDEs. I even used the concept on Linux for a while in the form of "RHIDE". It wasn't bad UX but the software was pretty badly written so in the end I dropped it. I never enjoyed anything as bare bones (or requiring such a learning curve and setup of adding) as vim. Right now I use VS Code. Not a huge fan of it and I really wish it was available as a TUI application but for now it seems to be the best around.
If you look at his screenshots you might think you were limited to 80x25 but with EGA and VGA you could pick a different screen size and get more vertical lines.
At the expense of vertically squished fonts, which I hated the look of. I would have been more likely to use it if it had a similar increase in the number of columns to keep the font at the correct aspect ratio.
On the Mac side, THINK/Lightspeed Pascal had all of the same unmmatched mod cons of Turbo Pascal: lighting fast compile times, unmatched symbolic debugger that understood record types and Macintosh handles with a variable watch/execute statement window, auto formatting. It was sad that the Mac world slowly converted to C/C++ as the "flag carrier" programming language.
No TUIs, ever. God forbid.
Borland Turbo C and it's debugger helped me implement my 1st scheduling optimization algorithm, get into production and got me a promotion. Ported it over to IBM mainframe with the help of a colleague which reduced run time to few minutes compared couple of hours on DOS/486
It looked so clunky compared to what my colleagues used in their DEC and SGI (6 processors I think) workstations had, but got the job done
Agree with all of this - I had exactly the same feeling going from DOS to Linux in the 90s and wondering where the proper TUI apps were.
In 1989, I got a IBM AT, with VGA. I flipped from a Herc card, with 25 lines, leaped past EGA 43-line mode into VGA 50-line mode. Turbo Pascal, and SideKick ( or psychic ) all ran perfectly. Paradise VGA w/ 512k. Sony 15" Trinitron, very sharp. Why don't other people program in this?
Wideprint had a 132 column mode for Lotus 1-2-3, and again, SideKick jumped in perfectly.
Seems a bit quick to dismiss modern TUI editors. Emacs in terminal mode has feature parity (almost?) with the GUI version.
And by the way classic curses like menu bar can be opened in text mode with M-x menu-bar-open which is bound to <f10> by default. You can even use mouse with xterm-mouse-mode.
The one he was looking at was text menubar emulation which is pretty powerful too if you take a minute to appreciate it.
He claims they are unintuitive so he didn't bother exploring them.
What is completely fair. Emacs in particular is more featureful than VS-Code, but hell, it's hard to make use of all of it.
If vertico and context-menu-mode were defaults you might not be able to say that.
Or just the menu and toolbar weren't immediately disabled by most.
I hope someone from Embarcadero is paying attention to this thread. They have had some great IDEs but their primary attraction was the price point and the ease of use of the products. Please make Delphi affordable again.
Considering that Delphi can be used for Android, IOS and Linux development as well, it would be a great tool - if it weren't for the insane pricing.
Coming up for retirement and I have made a nice business using Delphi; it's been the right tool for the right job and that is developing Windows programs.
I understand why Embarcadero did it, but for the dozen people who actually use Delphi for any OS other than Windows, and any CPU other than x86, they really should not have bothered.
30 years ago I was using vi and the shell on a Wyse 85 terminal.
Nowadays I used vim and the shell in one of many terminal windows on one of many workspaces.
Every now and then I try an IDE but I always find the loss in productivity and the lack of discoverability to be hampering. I'm there to get work done, not to stare at cartoons and fumble around for wherever the mouse or cursor has disappeared to again.
I forget if it were a MS or Borland thing, but I recall some of these DOS IDEs having an "expert mode" feature in the menus where you'd get, by default, only the most useful features, but could then turn on all the menu features by enabling said expert mode. Anyone remember this? Some tools (VS Code..) could sorely do with this today, I feel.
Here’s another very potent one from 40years ago that was popular and widely used for asm/c dev
Since the simple MS-DOS editors (which are not IDEs really) are listed, this one is a must have in the list.
https://en.m.wikipedia.org/wiki/Personal_Editor
I loved Multiedit Pro and Walter Bright's Symantic C IDE back then, besides emacs. Still with emacs, the others are gone.
Nobody (yet) has mentioned Microsoft PWB - Microsoft's Programmers Workbench for their C compiler, around 1990. It's what all the Microsoft engineers themselves used when writing code for Windows, WinNT, OS/2, etc. It was essentially perfect for its time.
ObjectMaster by ACI was pretty much the best OO IDE at the time. Pretty much everything on the Mac kicked the shit out of these pathetic and crappy DOS/commander interfaces that are linked in the article.
Unfortunately, there don't seem to be any screenshots of it online anymore due to link rot.
The glaring omission in the article is Visual Basic for DOS. It had a visual TUI designer in DOS. https://www.youtube.com/watch?v=-vDpzoYgNd0
Borland C/C++ 3.1 came in the largest by volume and by weight shrink wrapped box ever due to inclusion of printed library and API references for DOS and Windows and other tools.
Borland-branded products were the pro versions compared to the Turbo-branded ones.
If any dev out there is looking for a challenge/cool thing to do, here it is: a TUI DE following the practices of TurboC/TurboPascal, CUA visuals and keybindings from edit.com and support for multiple languages and LSPs.
TurboPascal and other Borlands IDE were great, but just a lesser version of FoxPro!
With FoxPro, you have the features of them, but also, RAD form/menu/table/report builder. Like "Let's add MS Access to your IDE".
That is the dream.
One of my goals is to built it!
So I've been using vim as my IDE for the last ten years. I've really enjoyed using it, but VSCode is super duper popular. Has anyone like me converted? If so, are you still using Code or did you go back to vim? If so, why?
I gave VSC a shot. It's the stupidest thing, but I just can't get over how the side bar (not the file explorer, but the little activity bar that you can open the file explorer/plugin menu/etc from) keeps re-appearing every time I open certain things. I know it's petty, but I can't get over it.
I was able to, mostly, get things to work the way I wanted in it, but that ended up meaning I turned it into basically my vim setup.
I've moved to jetbrains products at work. Same story there, I basically turned it into vim, and hid all the sidebars (but it does let me do this). Mostly I'm using it for the debugger, the jetbrains debugger is legit.
Still use (n)vim at home a lot, especially for anything that doesn't have a dedicated jetbrains ide.
Other than that, the only thing I've really had problems with is that graphical editors all seem to think in terms of files instead of buffers, and there's no equivalent to vinegar. I think that really throws me the most.
Moved to vscode with the neovim extension (vim mode was slow for me over large files). vsc is super customisable, and you can remove all the tab bars, side panels and anything else you don't use fairly easily. It's also far more stable than the neovim ecosystem, i don't have time to mess with neovim plugins breaking bi-weekly anymore
I did. I eventually got tired of fiddling with configs, not so great debug experience, copy paste issues etc.
Now I just use Vim mode in VSCode. Don't get me wrong, you also need to spend time on Configuring VSCode, but it's so much better.
I remember using Borland Turbo C++. It was the most convenient piece of software to get started with programming. If I had been introduced with anything else, I would have found it much more difficult to cross the initial curve.
Meanwhile, outside the world of PCs and DOS... https://youtu.be/uknEhXyZgsg?si=nx7IEAC9RZDwEeWY&t=3251
30 years ago there was Vim. 30 years from now there will still be Vim.
I fondly remember Borland C++ builder - it allowed me to write shareware apps for Windows without having to learn the low-level MFC API. I was a hobbyist, and it scared me :)
30 Years ago Watcom would be ripping through Borland's assumed monopoly and rapidly becoming the most used C/C++ IDE, only to have Visual Studio do the same to it in 2-3 years time.
15 year old me could use the Turbo Pascal debugger well because it was so intuitive. Now I’m just not comfortable with using debuggers at all and I keep spamming prints in my code.
I recently started building a little desktop app using C# .NET WinForms, and it was a tiny bit clunky at times, but strongly reminded me of building VB4 apps.
30 years ago - and from about 89-94 - my IDE was DataViews. Still all these years later I don't know of any IDE that can create such graphical interfaces.
No mention of the Microsoft C and Pascal IDE. They were somewhat similar to the QBASIC editor. Not as popular as the Borland counterparts
I'm not aware of anything so convenient and learler-friendly as Borland IDEs were.
Ahhh.. Borland TUI. But also Visual C++ was really great. With offline docs!
Windows was around .. what about GUI based IDEs? Visual basic?
SlickEdit was around back then, in TUI form. Fantastic.
I _think_ edit.com still ships with Windows!
Not the 64-bit version, surely. They're thinking about shipping a new TUI editor, though.
Sorry, gotta call bullshit on this post. There were several _good_ IDE GUIs 30 years ago.
Fantastic article, thanks for sharing.
XY-Write anyone?
so neovim is the sota of vim now?
I'm not a fan of any IDE brand or company. I'm a fan of features. Any respectable IDE must have the following features: - jump to declaration - autocomplete of fields and methods of an object - autocomplete or tool tips for function arguments - code templates - find all the usages of a variable, type or function - rename variables, function, types etc. all over the code base(and do it correctly not blindly like with sed) - select a piece of code and extract it into a function - select multiple fields and methods and extract them into a separate class - highlight pairs of parentheses, brakets, curly braces and be able to jump between them - highlight searches - show line numbers - search/replace text in current file or over multiple files(aka grep and sed but integrated into the UI) - be able to open a terminal in a pane - search for a type all over the code base - search for a global function or variable all over the code base - display tree of included files(for languages that allow including other source files like C++) - display tree of subtypes/supertypes of a specific type - display a list of all overrides of a method and be able to jump to them - semantic checks(e.g. check that the types of the arguments in a function call match those from the function declaration - of course for languages that have a type system) - display syntax/semantic errors as I type - a file explorer should always be easily accessible - automatically select the current file in the file explorer; be able to turn this behavior on or off - Copy the full path of the current file to clipboard - Copy the name of the current file to clipboard - Autoformat the code - Autoindent - Syntax highlight - debugger integration - build system integration - display an outline tree of the source code ine current file - have a local history of all the changes to a file - version control integration - diff between current and previous version of the current file - search files by name in the entire code base - when many editor tabs/buffers are opened, search through them by file name - spell checking in comments, be able to turn it on/off - generate documentation from comments - fold/unfold code blocks - replace tabs with spaces - show special characters - block editing - place coursor in multple places and perform the same editing changes in multiple places at once(like in sublime) - jump over paragraphs - jump to beginning/end of file - open documentation of function/class/type/etc. under the coursor - set bookmarks in code - have a history of searches and be able to redo older searches - list all TODOs/FIXMEs from all over the code base - split panes vertically/horizontally - textual autocomplete (meaning autocomplete if identifier is already present in current file) - linter integration - UML diagram generation - erase the current line with a single key binding - move current line up/down with a single key binding - display object instance tree - and possibly many others that I just can't remember right now...
Now I don't care if it's vim, emacs, vscode, eclipse or jetbrains offering these features. From experience I learned these features make me most productive...coupled with command line tools it gets even better. So if these features/tools are available in an IDE/tool suite then I'm a happy programmer and I will use them. I don't have time to be a fan of this editor or that editor...even though I do like to enable vim key bindings if they're available once in a while.
Yeah, no