It’s worse that it’s at a company. But I took a CS class in college that was an intro and the teacher had a pseudo-language that we had to hand-write and turn in to him to have him grade. It still pisses me off to think about how much I would have actually liked the class if I could compile code and see things happen. I changed majors because of that class… I did end up switching back at a different school when I tried a CS class that I liked lol
My work laptop has Windows installed, but I use VSCode and WSL or EC2 Linux instances solely for my work. VSCodium would not work with that workflow because it lacks the Remote and WSL functionality
Neovim, and secondly lazygit. I guess you could count tmux too. I live in the terminal
It’s just what I like man, it’s very customizable and wraps around my workflow instead of me wrapping around it’s workflow. I think about doing a thing and at a point muscle memory kicks in and the thing happens.
Nvim & tmux gang! I’m always happy to see a reasonable number of people mentioning vim in these threads. Need that affirmation that I’m not just a dinosaur.
Look at it this way: while everyone else is busy erasing their muscle memory in favor of the next shiny thing every couple of years, you can spend that time improving on what you already know. Its actually giving you an edge.
It’s actually kind of funny. Developers using Vim (or Emacs, Neovim, etc.) are often perceived as archaic, yet very profitiert and the assumtion is that being a very proficient programmer let’s them get away with using archaic tools. In actuality, I’d argue its the other way around. The fact that we dedicate time to mastering the tools of our trade leaves us with more capacity to actually become that proficient.
I just send highly trained butterflies in the atmosphere that cause air currents in the upper atmosphere to affect the path of cosmic waves which write the program in my computer’s memory
Mostly just Visual Studio Code, alongside the usual constellation of Git + assorted language toolchains.
It’s plug and play at every level - no need to waste hours fucking around with an Emacs or (Neo)Vim configuration just to get a decent development environment set up.
(And yes, I would use Codium, but the remote containers extension is simply too good.)
You can download any visual studio code extension from the visual studio extensions marketplace as far as my experience goes. There’s a “download extension” link for every extension which will give you a *.vsix file. Only pity is that you won’t get any automatic updates for the extension.
8 just took a look and the VS marketplace website on my mobile and look at what I have found under the “resources” section! This is same for every extension.
Unfortunately, it’s not that simple. The Remote* extensions rely on the (proprietary) VSCode server, and nobody has managed to hack it to work with e.g. Codium.
it relies on a proprietary blob + product.json config from proprietary vscode builds
there’s an open source remote development extension (works pretty well) but it currently only supports ssh
I currently use VSCode. I did use Emacs for quite a while, and it in itself is a fantastic editor (if not, an operating system :^), don't get me wrong. But I had a few reasons for switching.
Emacs is a very rigorous editor to configure, and whilst it comes with many features out of the box, a lot of those are either broken, or highly unfinished / unpolished, so it is effectively required to manually configure your environment. This also includes that the codebase for GNU Emacs itself is, and is still built upon, a fossil, and it can show it's age in a few ways. VSCode is typically ready for development out of the box, if not, easy to get set up using plugins, and customization usually just takes tweaking a few things in the settings.json at most.
Improved language support is a must in many cases. Emacs language support or LSP is usually good, but in some cases it can be quite unoptimized (for example, the Dart LSP client on Emacs does not run well whatsoever in my experience). On VSCode, the language plugins are quite often official, and can come with some extremely helpful features.
On this, Jupyter Notebook is absolutely perfect on VSCode. Yes, Org Mode works great, but Jupyter is typically the most expected in my usecase, especially in standardized data science. EIN works, but it's not nearly as smooth and efficient to use as the VSCode support is.
Again, Emacs is great, I configured my environment myself using parts from Nano Emacs, and a good Evil mode configuration is an ergonomic dream (yes, I also use VSCodeVim), but it gets tiring to maintain it after a while, and I just want something that works, and VSCode fits that bill, not just perfectly, but with flying colors to all of my other requirements.
Same here. I used to heavily use emacs, but when I changed job, it was much easier to simply use vscode instead of making emacs work properly in the new work environment.
Maybe if I find some time, I may go back to emacs since I miss a few features from it.
PyCharm. Does pretty much everything I need. Work paid for it.
syntax highlighting
auto complete and suggestions
find usages/definition
refactor
delete
move
extract
rename
git integration
SQL integration
steps into library code
connect to sources installed in docker
probably other stuff I take for granted and can’t think of now
I’ve had some coworkers who are more “steady hand and a magnetized needle” and I don’t know how they do it. Like I was collaborating with a guy and watching him manually find and rename stuff was painful. Though I think a lot of people just don’t know how to use their tools. There’s a lot of stuff in pycharm I dont use.
I’m still slightly salty about an old coworker that would use vanilla sublime and make PRs full of easily caught errors. “Can you approve my pr?” “No dude the linter failed. Did you ever set up any of the tooling locally?” “Nah”
Is pycharm’s semantic highlighting still kinda ass? That’s the biggest thing that stopped me from using it over vsc. As of like may this year i remember there still being active issue tracking for it.
Now it is my turn to be the guy with the steady hand and magnetized needle. I don’t think I use semantic highlighting unless it’s on by default and I never noticed . I might go check it out on Monday.
Do you remember what issues you were having with it?
For me the remote deployment and ssh interpreter are very useful. I develop on a Mac and deploy on Linux servers. Sometimes there’s a scenario where a library works on Linux but has trouble working on Mac. Rather than spend time working on getting it work on Mac, I just remotely deploy it to a tmp directory on a Linux server and setup an ssh interpreter on the server, and continue developing on the Mac. Very useful for me.
VS Code. It’s dead easy to use, has a ton of useful plugins, and it’s customizable while also being enjoyable to use right out of the box.
For AI assisted coding, I use Cody or GPT-4 data analysis on my personal projects. I tried copilot and found that it actually made my productivity worse. Often as not, I found myself stopping and second guessing whether I was stupid or if it was copilot, and it was usually copilot. GPT-4 is really great for problem solving a specific problem or getting some feedback on some bad smelling code, and Cody works great for helping to write my code faster.
What features does your editor have that other editors cannot provide? Seems like it would be easier to grab one of more popular editors and script/write a custom plug-in to suit your needs.
That was my starting point, and I changed because it wasn’t easier.
I switched because my Emacs config was thousands of lines of code to try to wrangle it to do what I wanted. My editor is ~3.5k lines of code and is closer to things how I want them. It’s spartan, and you and most other people would hate it. That’s fine - I have no interest in writing a general-purpose editor.
Writing a good general-purpose editor is immensely hard, but writing a small editor for yourself is not.
I could absolutely manage to squeeze everything I want into any open-source editor and many proprietary ones via extensions, but there’s no value in that to me when I can write less code and get something that’s exactly adapted to my workflow.
For starters, I use a tiling window manager, and there are no editors that are designed with that in mind. That doesn’t mean they work badly with them, but that e.g. they spent a lot of code on window and tab/frame management that my window manager is already doing the way I want it, and so just by making my editor client-server (a few dozen lines of code with Ruby via DrB), I got that “for free”: When I split a view in two, I use the API of my window manager to halve the size of the actual top level window and insert a new editor instance that observes the same buffer. I could retrofit that on other editors too, but doing it from scratch means the “split a view in two” code in my editor is about a dozen lines of code.
Another example is that for my novels, the syntax highlighting dynamically adapts to highlight things I’ve taken notes about (e.g. characters, locations). I could do that with another editor too, but having full control over the way the rendering layer works meant it was trivial to have my custom workflow control the lexing.
My advice is to start small, and look at some simple examples. E.g. I knew I wanted mine to run in a terminal, and I love Ruby, so I started with Femto which is a really tiny Ruby editor. By itself, it’s pretty useless (but beautifully written), but it was remarkably quick to get to something that was “tolerable” for light editing, and then I iterated from there.
There are many options for small ones for all kinds of different values of “small” that can serve as inspiration. E.g. Linus Torvalds has his own branch of MicroEmacs (as do many others, it’s a popular starting point, and the basis for e.g. Pico, mg, Vile). Antirez (of Redis fame) has Kilo, so named because it was written to be <1k lines excluding comments, and there’s an “instruction booklet” on how to write one that’s using Kilo to demonstrate approaches to writing one.
The first starting point, I think is deciding how general you want it to be. E.g. I early on decided I don’t care at all about being able to use it as my only editor ever, and that meant I could pick and choose use-cases that were out of scope. For example, I just want to edit “human-scale” files, not multi-GB datasets or log files - I’m happy to open that in Emacs if I ever need it - and so that gave me far more flexibility in terms of data structures because I don’t need it to scale beyond a few thousand lines, and that saved me a lot of effort.
Emacs. I’ve created a niceish workflow with it. I really like how it’s so easy to change anything. There are also loads of incredibly useful plugins, so that’s cool.
Platform independent, and “just work”. Not missing any functionality I ever wanted and with a new machine even CLion’s almost legendary slowness is under control.
Add comment