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.

It was just brilliant.

These days every application reinvents its own controls for everything. For example, in a web browser the tab bar and address bars are totally custom controls. Electron apps like vscode take this to the extreme - I don't think vscode or spotify use any native controls in the entire UI.

I blame the web in part. It was never designed as a system to build application UIs, and as such the provided UI primitives are primitive and rubbish. Developers got used to building our own custom elements for everything - which we build fresh for every client and style in alignment with the brand. UIs built on the web are inconsistent - so our users never get a chance to learn a common set of primitives.

And for some reason, OS vendors have totally dropped the ball on this stuff. Windows has several competing "official" UI libraries. Every library has a different look and feel, and all are in various stages of decomposition. Microsoft's own software teams seem as lost as everyone else when it comes to navigating the morass of options - if windows 11 and MS Teams are anything to go by. Macos isn't quite as bad, but its still a bit of a mess. Every year I expect the people building xcode to know how to build and debug software on macos. And then xcode crashes for the 3rd time in a week. Xcode achieves the impossible of making the javascript ecosystem seem sane and attractive.

I'd love a return to the halcyon days of vb6, where UIs were simple and consistent. Where there was a human interface guidelines document that UI developers were expected to read. I want users and developers alike to know how the platform works and what the rules and conventions are. F it. How hard can that really be to build?

https://guidebookgallery.org/pics/gui/interface/dialogs/colo...

... But limited to only allow you up/downvote between -1 and 1.

Everything else could be done with buttons and a TextField / Label for comments and replying.

The web is a bit weird in that it taught us to build every UI as a giant scrolling document. And HN is no different. A more "classic" UI approach would be something like Thunderbird mail - with 2 panes: a "comments" tree on top and a "message body" down the bottom. That would be harder to read (since you'd need to click on the next message to jump to it). But it might encourage longer, more thoughtful replies.

Thunderbird: https://lwn.net/Articles/91536/

Or you could reimplement HN with classic controls and something like TB 114's UI:

https://www.ghacks.net/wp-content/uploads/2022/08/account_ma...

Probably still worse that what HN is now though.

It really isn't. Web is anemic in controls and layouts compared to what's actually possible with proper controls and control over those controls.

C# with WinForms is still usable today and provides a similar experience. Although the design language has fallen out of fashion.

For me, WinForms always had an element of struggle not present in Delphi

Bill Gates demoing it from 32-years ago.

https://youtu.be/Fh_UDQnboRw?feature=shared

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.

Money? Internal elitism?

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.

VB created applications that had to ship with a shared runtime library. Windows wasn't great at versioning these libraries so developers often shipped their own VB runtime with their executable. The executable was small and the runtime was comparatively huge which had a negative impact on user perception when downloading the installers.

Before moving on to Microsoft in 1996, Anders Heilsberg was the Chief Engineer at Borland that oversaw the development and release of Delphi 1.0.

For years, VB felt like an application that could make deployable versions of itself. Delphi felt like a programming environment that compiled code into applications.

After Heilsberg moved to MS, a lot of improvements were made in VB that utlimately made Delphi less attractive, especially during Borland's strategic waffling known as "The Inprise Years": https://en.wikipedia.org/wiki/Borland#Inprise_Corporation_Er...

If you want to get a feel for what it was like then check out the FOSS clone "Lazarus".

Well, not actually. With Anders' move to Microsoft, VB6 (aka, VB "classic") was discontinued. Microsoft supported Visual Basic syntax on the .NET runtime, but the vast majority of VB programmers considered this to be a different language because developing for the .NET Framework (remember this is ~2001) was a huge departure from VB Classic.

Many VB developers petitioned Microsoft to open-source VB6 or continue releasing improvements on it. Microsoft did not and chose to continue with their .NET + C# strategy.

At the same time, I was playing with Linux at home, and wanted tooling that could run on either platform. I learned Python at home, and then made the switch at work.

One of my last VB6 apps, thousands of lines, has been running in the plant without issue for 15 years. On one occasion I had to bump up the declared sizes of some fixed length arrays.

As for GUIs, I never found anything close to VB, but also decided to just write a thin wrapper around Tkinter and let my layout be generated automatically by default. I haven't missed laying out my GUIs, which were always a hodgepodge anyway.

VB5 in 1997 and VB6 in 1998 really closed the gap with Delphi from what I remember.

This is (from Borland's telling) not an accident. https://news.ycombinator.com/item?id=29513242

Hard to not waffle when your major competitor hires away your top talent.

The VCL component library in Delphi is still unmatched in native code – very comprehensive built-in (and commercial) components, and customizable. Plus, Delphi's database connectivity was unparalleled and can be setup in the designer where you could see data queried and returned live in your grid component!

Delphi also supported advanced language capabilities (when compared to VB), like inline assembly and pointers, which were essential for low-level optimization or system hacking. The robust error handling in Delphi was another plus compared to VB's older 'On Error' style.

1. The component architecture was just great - I have yet to see any language/platform with a more sophisticated component structure even now.

2. There were all sorts of free and commercial components that you could download and install into the IDE and have it running in your application in next to no time. ActiveX etc didn't even come close to the level of integration and speed that the Delphi component architecture provided.

3. Components could be loaded into the UI during the design time itself and you could see it functioning directly within the IDE when you place it on your form. Example: You could connect to a database, run a query, put that into a table with all sorts of sorting and navigation functions and you could see this working even without compiling the 3pplication.

4. It was trivial to develop components for Delphi - even though it was so sophisticated. You could develop one in about 15-30 minutes.

5. The compilation speed was just insane. It just blew everything else out of the water and so you could do fast compile+run cycles.

VB was easier to start but Delphi was nearly as fast to build, code was compiled (fast!), Object Pascal supported OOP and the UI features like visual form inheritance I have yet to see implemented anywhere else.

It's more that few people want to make and distribute small desktop apps anymore.

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.

    Mr.Ms.

you can try it in your url bar: data:text/html,Mr.Ms.

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

Also your two examples are drawing canvas examples, thats a pretty different target that delphi / vb6 have with their GUI toolkits.

Additionally, use of `@container` queries (the modern, poorly-documented alternative to `@media` queries) lets you do more advanced layout changes on element resize. This requires adding `container-type: size` style on the parent (I found this very confusing in the docs).

i have no idea what segment, revenuecat, mixpanel, datadog, sentry, etc., are

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 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

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 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.

GP did IMO the right thing by understanding the audience first in order to judge what level of context is appropriate. That should be rule 0 before anything in Diataxis gets involved.

- 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.

Eh, more like it walked rather than ran :-P.

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 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.

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 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.

- docker containers - accessing boxes on same network

Sometimes its fine, but then perhaps because of regressions, I get buffers that never seem to recover and have to be cleaned up.

No, you weren't doing this. You were making a round trip to the server when you moved the cursor or selected text.

Of course this being X, your machine ran the server and the remotes were the clients…

Also it is impossible by laws of physics by using distributed computing, not having each keypress and its display on a rendering surface, being a two way street.

The idea with VS Code is that neither the keypresses nor the displayed windows are being sent over the network, but are kept within the same machine where the user is entering or viewing them. Only the file data (or debugger status, etc.), which are cached and far less frequently updated, are sent over the network. Are you saying that XEmacs can also function remotely in this way, with neither keypresses nor displayed windows sent over the network?

That's better than SSH for sure, but still not as good as the web model.

The client is the server application.

Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.

There is no difference between doing this over text or graphics, in terms of the whole setup regarding network communications for data input and output.

Thisnis very different form a system, where each keystroke and each menu action has to be transfered first, before the remote side can identify the needed UI update and send that back

Not going to waste more my time explaining this.

Arguments to authority aren't appealing. Arguments from logic are. The fact is that X and VSCode's remote protocols are designed very differently, and in high-latency and high-jitter connections (and many low-bandwidth ones), VSCode's protocol is simply better.

VS Code's "backend" that runs on the remote machine is rather only in charge of more "asynchronous" operations that aren't part of the UI's critical path, like saving files or building the project. It doesn't speak anything as granular as the X protocol.

Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?

The client application (on X Windows nomenclature), runs on the remote server and is headless.

Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.

Everything else regarding compilers, subprocesses and what have you keeps running on the server, regardless how the connection is made.

Think big X Windows terminals or green/ambar phosphor terminals accessing the single UNIX server, used by the complete university department.

> Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.

(Simplified) VSCode is sending no bytes to a server when you're editing a file. The entire file exists on the client, you can edit all you want and everything stays on the client. Only when you pick "save" is a data sent to the server.

My understanding with X Windows is as you mentioned above, you press a key, that key it sent app on another machine, that other machine sends back rendering commands. Correct? Vs VSCode, you press a key, nothing is sent remotely

Note: There's more to VSCode, while it doesn't have to send keystrokes and it is effectively editing the file locally (so fast). It does send changes asynchronously to the remote machine to run things like the Language Server Protocol stuff and asychronously sending the results back. But, you don't have to wait for that info to continue to edit.

"""The X server is typically the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X server is usually running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user's computer to request the rendering of graphics content and receive events from input devices including keyboards and mice."""

As the author states, IDEs haven't necessarily gotten a lot better, but imo advanced features have become a lot more accessible.

I absolutely agree, assuming you're using "powerful" in the same sense as saying that a Turing machine is more powerful than a MacBook.

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.

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).

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...

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).

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).

[0] https://www.gnu.org/software/tramp/

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.

This is the step that never works consistently for me. There is always some amount of random extra latency that makes the this workflow painful. I work with some extremely large data files, so random access to these is the primary issue.

In general, the idea is that it is often better to do compute where the data already is. My experience is that you should also do the programming closer to where the data is as well. This tends to make an iterative development loop tighter.

But this is highly dependent upon what you’re doing.

It's funny because my reasons against using a text editor remotely are exactly the same: to make the development loop tighter. I am very upset by latency and always try to remove it where possible. I think this is the kind of thing where we'd need to look over each other's shoulders to understand our respective workflows.

That’s exactly what I’m doing. The code is written on the remote server. VSCode’s remote setup is actually very good at this. Mainly because, it is really a web editor that is hosted remotely and you use a local browser (Electron) to interact with it. The processing loop then happens all remotely.

But really, I’m talking more about data analysis, exploration, or visualization work. This is when I need to have good (random) access to 100’s of GB of data (genomics data, not ML). For these programs, having the full dataset present during development is very important.

If I’m working on more traditional programming projects, I can work locally and then sync, but recently I’ve been using more docker based devcontainers. These are great for setting up projects to run wherever, and even in this case, the Docker containers could be hosted remotely or locally (or more accurately in a VM).

That said, you can also open a terminal in vscode and use grep. If you’re running remotely, the terminal is also remote. That’s what I normally do.

Why?

Which is also immediately mentioned after the claimed that using a remote editor is silly.

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.

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.

It just updates now, and I export my installation XML and send to people when they want the exact same IDE I use.

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).

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.

First, it was quite common for a company to buy a developer the exact same corporate standard computer as everyone else. So lots of computers had limited ram to run things like J2EE, Lotus Notes, and Eclipse at the same time. It was painful.

The startup was always slow because it preloaded everything. This was a deliberate choice to not load things and interrupt the developer. Just don't close it all day and the experience was very good.

A plus compared to the standard of the day was that it ran native widgets. So doing something as simple as opening a file explorer to browse through your project was considerably faster than comparable IDE's at the time.

Personally, I loved the customization which was dialed all the way up. I could have multiple windows with different arrangements of panels within them, all saved. I haven't run across anything as configurable since then.

It also had the big benefit of their plugin system which shined when working with multiple languages in the same project.

It always felt to me like it became trendy to crap on Eclipse because of the slow startup time and it never could shake that.

I tend to close and run the IDEs (and most programs) multiple times per day - a clean desktop kinda lets me clean/reset my thoughts - so long startup times are annoying. Of course i wouldn't avoid a program if it was responsive, fast and did what i wanted after it started up.

> 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".

Yeah i also had a single workspace but i worked in a bunch of other things, including some Java stuff in NetBeans and i want to have everything in one place. I do use and prefer IDEs but every other IDE could just store projects wherever i wanted.

9 seconds of startup time on a modern GHz computer is completely unnecessary and unacceptable IMO. There may be 9 seconds of work it wants to do at startup, but there's no way it needs to do it in a single thread before letting you start to interact with it. This is an optimization effort, nothing more. Give me a month with their codebase and I could get that down to under a second. (So could most decent software engineers.) It would just need to be something they actually put effort into.

In the following seconds, updates are checked and indexes of your open projects are verified and re-run if necessary which takes again

If you think that code is not optimized in the last 20 years, you’re mistaken. Many tools from Android Studio to Apache Directory Studio runs on that platform.

Nevertheless, I’ll try to profile its startup tomorrow if I can find the time.

Normally Eclipse IDE is not something like Vim, which you enter and exit 10 times a day. It just lives there and you work with it. 10 seconds in the morning for a tool that big is very acceptable, esp. after considering that everything is instantaneous after that 10 seconds.

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.

Tuning startup heap size could cut upward of 40% off of startup and settling time.

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.

i really despised (to stay polite) everything about eclipse/java culture.. lots of generic layouts and components, nothing i cared about or bringing me dense information about code. way too much chrome and perspectives and what not. it was a cultural dead end, the people who "enjoy" working this way are on a different axis from me.. give me emacs+magit where things are right under your fingers and easy to extend.. and people using this kind of tools (i'm sure vim/neovim crowd likes that too even more) produce more tools of that kind

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.

For Java specifically i felt NetBeans was faster and simpler though i bounced between it and Eclipse because i also used Eclipse for other stuff (C++ mainly) so unless i wanted a GUI i used Eclipse. I did stopped writing Java some time ago though.

I did try a recent NetBeans build but i found it much less polished than what i remember from before it became "Apache NetBeans".

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.

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.

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.

You will find old rants from me complaining about workspaces metadata, but that problem has been sorted for quite sometime now.

Eclipse is Visual Age for Smalltalk reborn, after all.

It was common to have plugins corrupt its metada, but somehow it finally became quite stable.

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.

In any case, it's a younger product than the offerings in the article.

[1]: https://www.st.com/en/development-tools/stm32cubeide.html

Yeah, but my gripe was about the closing of the article, which mentioned VSCode. I think the author just doesn't know about it.

Eclipse is my DeFacto C++/Python IDE and I'd love to develop a decent Go plugin for it, too. Maybe someday.

I’m sure it’s really good these days. But I’ve moved on now and my current workflow works for me, so I don’t see the point in changing it until I run into issues again.

I developed Java with Eclipse, but the project I did was not that big when Eclipse was not its prime, and it was in its prime when I was experienced enough to be able to "floor it" in terms of features and project complexity.

Now it's just a blip on the memory usage graph when working with big projects, and way way more efficient than the Electron apps which supposed to do 20% of what Eclipse can do.

This context is built up based on what part of the code you work on.

Running m1 sonoma

I do agree intellij is memory hungry with multiple projects open and a variety of languages involved, but RAM is cheap enough (and VMs/Docker/K8s hungry enough) that I just don't buy a machine with less than 32GB anyway, so I give intellij up to 6 GB and never give it another thought.

I don't do much android development, but do find Android Studio to feel clunky and slow at times, guessing because of the heavy integration with Android dependencies and emulation, but not really something I know enough about to comment with any sense of authority.

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 :)

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.

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!

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.

Eclipse was created over that extremely interesting idea that you can write a plugin to do some completely random task, and have all of it reconfigured on the perfect way for that task.

But you can't have a rich ecosystem of plugins without organizing them in some way, and nobody ever created a Debian-like system for them as it's a lot of thankless hard work.

Writing rails api with a nextjs ui, anyone got any suggestions on alternative paths i should take?

RubyMine on a cancel anytime personal license is $22.90/month (or $229 for a year). That's nothing. I'd say just try it. If you don't like it, you might only be out $23.

I'm not a Ruby person so can't comment on that really. For Java (and C++) it's a lifesaver. Things like moving a file to a different directory and it'll update all your packages and imports. Same with just renaming a class or even a method.

The deep syntactic understanding Jetbrains IDE have of the code base is one of the big reasons I use them.

thank god

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.

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.

Windows could have been like Android, regarding the extent of managed languages usage and NDK, if DevDiv and WinDev had actually collaborated in Longhorn, but I digress.

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".

Agreed, I'd be infinitely less productive if I couldn't use the editor I learned to master in the past 20 years.

A corollary to that would be "pick a company that lets you use your own editor". There's lots of friction from IT departments towards emacs and vim. The package/plugin system is a security nightmare with lots of potential supply chain attacks and more importantly no trusted vendor to blame when something goes wrong.

There are some very short/simple demos on YouTube:

https://www.youtube.com/watch?v=m_3K_0vjUhk

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).

Or, use Lazarus/Free Pascal, which is almost identical, except for the documentation, which needs a massive overhaul, in tooling and content.

Those can profit from very latest version.

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?

[0] https://i.imgur.com/CAyu5Ay.png

[1] https://github.com/josvanr/cde-motif-theme

[2] https://i.imgur.com/Yw1tTcD.png

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

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.