231–240 of 698 posts
Earlier quoted context omitted.
JetBrains has Rider for C#
Yeah but you need to pay separately because it’s based on ReSharper, there’s no .NET plug-in for IDEA Ultimate.
Cheaper for personal use, and free for students.
https://www.jetbrains.com/idea/buy/#commercial?billing=yearl...
Question I have for everyone who doesn't use an IDE What is your workflow? I find the following to be true, in that one of 3 things happens inevitably: 1. The Text Editor becomes the IDE, (e.g., with VSCode, if you just live in plain HTML, CSS/SCSS/LESS and JSX/TSX/JS/TS all day, its actually pretty great, lots of well maintained extensions and Microsoft really put their energy into capturing into this market with VS…
The UI is an absolute mess. "Check for updates" immediately shows "Downloading updates". That's not what I expected. How about some confirmation? Start a .NET project and you see "Downloading package 'OmniSharp for OSX' (49713 KB)", "Downloading package 'Razor Language Server (macOS / x64)' (51227 KB)". No prompt. Just starts downloading 100MB of deps. For some reason the Output tab down the bottom has 20 options in…
Compared to jet brains though? Id argue its a huge improvement.
When I used Rider at my last job, it would pick good auto defaults that you could customize based on the project configuration, including automatically generating IIS express configuration values.
Are there more explicit downsides you can mention?
I completely switched to VS Code once I discovered the remote development feature [0]. It allows you to run VS Code locally but work on a project in a different environment (via SSH, Docker, WSL). The integration is seamless - search, debugger, terminal, extensions - everything looks and behaves as if it was running locally but is delegated to the configured remote. You can even have different remotes opened at the s…
This is such a hugely undervalued feature, and no other editors seem to provide anything remotely close. I found it particularly useful for the COVID work from home - I yeeted my work laptop into a corner and just SSH into it to continue working with the ergonomics of my home desktop machine.
I completely switched to VS Code once I discovered the remote development feature [0]. It allows you to run VS Code locally but work on a project in a different environment (via SSH, Docker, WSL). The integration is seamless - search, debugger, terminal, extensions - everything looks and behaves as if it was running locally but is delegated to the configured remote. You can even have different remotes opened at the s…
I've used almost all popular editors for years, Vim, Emacs, Ultraedit, Sublime and of course VSCode. But I switched back to Sublime about six months ago. VSCode is mostly impressively good, it is even quite fast for an electron app. But still, not as fast as Sublime, and I think it degraded at some point, and I could sense it during work. And then, I might be a bit paranoid but I think that VSCode could be used as a…
Earlier quoted context omitted.
Text editing is mostly a solved problem, and arguably done better elsewhere. VS Code makes improvements on interacting with particular languages / DSLs.
Of course text editing is a "solved problem," just use a #2 pencil. Solving a boring problem better is a thing new technology often does.
I find this post along with the comments in "A Picture of Java in 2020" https://news.ycombinator.com/item?id=24551390 to be incongruous with my experience as a professional developer. My first couple of years writing software I used Vim, then VSCode, then worked in a Java shop and was forced to use IntelliJ. I didn't like it at first, but now after a couple of years I cannot see how I lived without it. The idea that…
Personally, I'd rather use a plain-old "code editor" (with at most syntax highlighting, but no snippets, let alone autocomplete), in part because doing so will actively steer me away from languages that weren't designed with the User Experience of writing them in mind.
Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. That'd be a bad hammer, right? Hammers are hand-tools; it's an expectation that they'll work when used "manually", i.e. with raw human capability alone.
Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye. That's kind of the idea behind having a source code representation of a program in the first place, divorced from a machine code representation — to give us humans a formalism we can intuitively handle. A programming language is something you can think in.
Seen through that lens, a programming language that requires the cybernetic prosthesis of an IDE to read and write it fluidly, is a bad programming language. You don't have an IDE loaded in your head. So how will you think in it? (Usually: by thinking in a vague pseudocode instead; or even, by thinking in a different language than the one you're writing in. Obviously, this is going to be lower-productivity than coming up with a mental model of the problem that can be directly typed into a computer.)
(Before anyone makes a supposition about my language biases: both "complex" and "simple" language designs can be inherently high-friction due to their design choices. Scheme has very little syntax, but it's also high-friction, in that it's easy to get lost in a sea of parens unless your editor helps you along with a feature like Emacs' paren minor-mode. Most modern code editors do have something like that, but it's still a form of lubrication to overcome a point of friction in the syntax; one that some of Scheme's linguistic siblings—e.g. Clojure—avoid by increasing syntax.)
But I don't love it. Nor do I think it's the perfect code editor, or that we're in an Era of Visual Studio Code by any means.
I still find that I spend most of my time in vim as it is fast, and suits my development needs well without getting in my way.
Earlier quoted context omitted.
It seems like Emacs shares the same product philosophy of VS Code. Outside of the core functionality everything is an ELisp/Javascript plugin. That explains Emacs amazing longevity, but as the article points out, Emacs longevity is actually a problem as its keyboard and UI conventions predate the modern conventions that came with Windows and MacOS.
The difference between VSCode and Emacs is the difference between an extensible text editor, and an editor that was designed to be extended, molded, and shaped as you work. At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality. What's more, the always-on presence of Lisp turns Emacs into a computing environment with strong editing primitives, rather than a text editor with stuff b…
Your answer: Learn Lisp!
Technically true even in spite of emacs, but if every engineer out there learns lisp to write better python wouldn't that be an interesting world.