That's exactly why I stopped using Svelte. Claude is much more sensible when generating React. Looks like a bleak future where only the most popular library survives.
That's not a typical leetcode problem though. Most companies ask things like "solve this slightly modified knapsack problem" which takes 5 minutes if you know the solution and 50 minutes if you don't.
Yeah, it's very intentionally not a typical leetcode problem, precisely because leetcode is nearly worthless for screening people these days. I was replying to someone who seemed to be objecting to my opinion of some candidates' skills on the basis that maybe they just didn't know the specific thing we ask.
I found VSCode's remote plugins to be a really good option when the code lives on a shared remote machine over a slow connection. vim+scp is an extra step on each change, vim over ssh is just awkward, and sshfs isn't the most reliable piece of software.
What's wrong with vim over ssh/mosh? I was taught emacs by a grad student back in college and the ability to be fully productive on any server where I can install emacs has been a huge benefit to my career. I can't imagine vim is much different in that scenario.
These days you don't edit things on servers. The most you might do is edit a file and change a single option. You can do that in vi, vim or nano. Certainly you don't get to install you favorite editor (and version) and the .config folder an every server.
Most of the time you'll be editing config locally on your laptop and it'll get pushed to the servers via config management or whatever.
Your laptop is the place for your tricked-out IDE with 27 plugins
Most people don't use vanilla vim, from what I've seen. It's not so great, out of the box. Definitely not comparable to any remote editor these days, that also supports vim navigation, like VSCode.
Integrated linters save a lot of time with their immediate feedback. Depending on the language you're working with, remote debugging can be an incredible time saver. Modern editors are aware of the structure of the code, so can do things that are impossible for default VIM to do, like find the usage of a variable, rather than text occurrences, automatically show documentation, etc. All time savings.
Agreed, good points. I guess I still wonder whether these are needed for an introductory assignment. A vim/ssh workflow seems more future-proof than any particular IDE. As an instructor maybe it would make sense to do the first assignment with low-level tools, then introduce VSCode/etc and briefly demo these things, to make the added convenience even more visceral to the novice.
> would make sense to do the first assignment with low-level tool
Sure, but if the goal is to teach programming, I think vim massively confuses a beginner. vim is hard for beginners, famously so. Something like VSCode, used as a remote text editor, is trivial and familiar to anyone who has used at MS Word. I agree it should be introduced, but there's definitely some cargo cult around vim and "the old ways".
Idk, if we're working on a remote machine already, it's not the student's first day. The bar to basic editing with vim is pretty low. Mode switch with i and esc, :x to save/exit, navigate where your fingers already are, slash to find. That all fits on a sticky note if it isn't already memorized in the first 30 seconds. They've likely played video games their whole lives, I struggle to see how mapping buttons to behaviors is a foreign or difficult concept.
As you say we're teaching programming. The ability to pick up an unfamiliar tool and get to know it on the fly is critical and the only way to develop it is practice.
That said, maybe there is no right answer here. I imagine the instructor's broader approach will make the difference, not which editor they make the class use for assignment three :)
I learned vi on a Tandy Model 16 running Xenix. The Xenix console driver, for whatever reason, throttles comms to the display to 9600 baud. It was fine. Today a "slow connection" is megabytes per second. Latency may be an issue, but otherwise vim, or any terminal-based editor, will run nicely over any modern connection.
By contrast, VS Code needs to inject itself, plus any plug-ins, over to the remote side. Wanna know how long that can take if the link isn't decently fast?
This kind of stuff requires access to the complete architectural parameters of the device, so adding support for even a single device family is a huge reverse-engineering^W documentation effort.
See f4pga.readthedocs.io which consolidates pretty much everyone's efforts into a distribution, but supports only 4 device families: iCE40 and ECP5 from Lattice, some 7-series devices from Xilinx and EOS-S3 from QuickLogic.
For internal testing, VPR has "Stratix IV-like" and most recently "Stratix 10-like" architecture files but these don't try to "document" the whole thing, they just want a close enough approximation to a modern device to evaluate the tool better.
Possibly, that'd be one of the "major architectural changes" that I mentioned earlier. Things we've simply not tried yet because they are too radically different from the way hardware currently works.
