If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production environment.
On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything simply works, and we can focus on the actual coding rather than messing around with our configs.
My experience of VSCode _is_ messing around with my config, but giving up and going back to a more mature editor because I could never get it to do what I wanted. I suppose capitulation was also an option, but I dislike the characterisation of tooling as something other than ‘actual coding’.
That's very strange, when did you use it? And what config did you need? In our company there really isn't any config we mess around with, just download the language plug-ins and that's it. If someone wants to add more then that's fine but not required.
I have a setup that I maintain and I pop back to it every six months or so. There are probably three classes of things that end up turning me off.
1) VSCode is very UI heavy and doesn’t allow consistent keyboard and text navigation. I want my text editor to be text-based, and it slows me down to have different types of windows (some of which seem impossible to hide permanently) with inconsistent forms of navigation.
2) The terminal window is its own thing, even if you open it in an editor window, which is then ignored by anything that interacts with the terminal. This is more what I want but is very limited and immature:
The lack of an infrastructure like Emacs comint mode also means there’s no good text-based database mode either. I want the same navigation, search and editing functions in every single window I have to interact with.
3) Where analogues to Emacs modes exist, they are universally less featureful, often because of fundamental limitations of the VSCode extension API. REPLs do less and offer less programmability. Edamagit is a fine and welcome effort but not as good as Magit.
If people want an editor with a little bit of auto completion and some squiggly lines to tell them they’ve typed something wrong VSCode is great. I have many mostly happy VSCode users within my organisation. But I think every individual programmer, like every team, should have a regular little retrospectives with themselves. What work did I do today, what would have made it flow better? In every case, I can build that in Emacs, but it’s much more friction in VSCode. This is partly immaturity and partly the APIs not offering as much. Long term I’m rooting for VSCode because it’s snappy and has undeniable market share. But it’s never quite been there for me yet.
Sounds like junior web devs working on Javascript pull-in-the-whole-internet code bases. Not criticising your choice, it might be the best solution to your specific challenges; that just does not sound like the environment I work in. If somebody can't configure their own editor and its dependencies, I wouldn't trust them to handle application dependencies in the supply chain either.
Then again, I might pre-date the which editor to use and how to configure it era.
For seniors, sure that makes sense, use whatever editor you want, but for onboarding juniors, we definitely have a recommended toolset just so we can make sure there aren't incompatibilities and that their productivity is still high, ie having a debugger when needed, using code completion, error checking, linting tools etc.
My point is you could configure all this stuff in Vim or Emacs but it's not as straightforward plus it wastes time when onboarding. We'd rather have an IDE like experience.
I don't understand, what config is necessary to work on the same codebase? Whatever program I use to open source code, eg. emacs or vscode, shouldn't matter should it?
The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand for me.
It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.
Yes, that makes perfect sense. If they want to set up an alternative editor, doing it on their own time is a reasonable expectation. No question vscode is millions of times easier for juniors.
These kinds of hyperboles are really really bad. You are stating that if it took 1 minute to install a plugin and get to work in vscode, it would take 694.4 days to do the same in other editors? Please use reasonable numbers if you are trying to make a valid point.
Not just 'other editors', I was thinking about emacs specifically. I think my point was fairly obvious. Maybe not a million times, but probably hundreds. Vscode and other modern editors use key combinations everyone knows by default, eg. C-q, C-c, C-v, etc., have gui directory browsing- so there is essentially no learning curve.
It takes weeks (at least) using emacs/vim until text editing/movement starts to pay off. There's no learning curve for `M-x package-install`, but if there is some variable that needs to be customized, like the path to an executable or something, that's a whole rabbit hole to go down, and at some point you need to learn lisp or you'll waste a lot of time being confused by errors.
During the only programming course I took in college, one in which emacs was required, I spent as much time learning emacs as anything else (it was also the most valuable thing I learned so I'm grateful in the long run).
> Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs.
Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs!
I honestly don’t understand why anyone bothers wasting effort on any other editor.
Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival.
Great tools are obvious in their base functionality and have optional additional layers that can be discovered if necessary. When you have to search the web to find out how to close the editor you just opened, because it works differently than every other program running on your system, you know you're using a bad tool.
No, good tools absolutely require learning how to use them.
To think that they don't is a maddening take because it has led to the infantilization of applications in so many areas of the software world.
There is definitely a place for simplistic tools that have no customization, no configuration, a single limited way to do anything and no hooks/APIs to modify their internal behavior. Yes, such tools are easiest to pick up and casually use in the limited way they can be used and that's often all that is needed.
But, the world also need professional tools. In the non-software world this is obvious and such tools exist in every profession. Even your hammer example is wrong as the sibling post noted, there are "professional hammers" (nail guns) that require a bit more care to use but are much better.
There is a place for test lights (that anyone can touch to a wire to see if there's voltage). But we can also buy voltage meters of increasing complexity and capabilities. They start to require a little bit of understanding of volts and amps and ohms, but they are so much more useful. But yes you need to learn a little to use them. There are also things like oscilloscopes which an untrained person wouldn't stand a chance to know how to use at first sight. But of course they are vastly more useful once you learn the tool.
Just one random example of thousands. Yes, good tools absolutely require training.
>Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival.
You mean like a nail gun? The kind that all professional roofers use?
Considering that nails from a nail gun have a habit of following the grain in surprising ways (possibly causing the nail to do a 180 degree turn and find your finger), yes, it is important for a prospective user to "get to know it".
Step inside a woodworking- or machine shop sometime and see how many of tools there you can instantly use with proficiency, with no instruction. (Please stand back from the table saws while trying this experiment.)
It’s wonderful and beautiful that we can get real work done with a heavy thing on a stick, but pretending every tool can be as simple as a hammer is not really arguing in good faith.
I’ve seen so many people use a hammer wrong. They don’t swing it effectively, hold it too high on the handle, or even use the wrong type of hammer for the job (yes, there are different types of hammers designed for different types of hammering).
And that’s before you go into all the other technologies invented that are evolutions of the hammer, from nail guns to jackhammers.
So any tool that is complicated enough to use that it requires more than 5 minutes to understand can't be a good tool? That is just false.
Obviously vim is not the tool for you (and emacs probably isn't either). You don't like the way they work, so don't use them. They are not bad tools. They are both very good tools. They are just not tools that fit your preferences. They do fit other people's preferences.
There are more complex problems than "nail" requiring more complex tools than "hammer".
And even the hammer metaphor falls apart pretty quickly: compressor driven nail guns are commonly used.
VSCode is obviously has something going for it, else so many people wouldn't be using it. Vi and Emacs are also extremely popular and have been for decades.
This is completely wrong. Basic tools that solve basic tasks are easy to learn and understand.
I use spectrum analyzers to identify partial discharges in high voltage equipment. Sometimes I use a hammer.
One of them require deep knowledge, with the other one I just give the equipment a whack with to see where the fault lies.
An operating theatre is filled with tools that require decades to master and years to learn to use originally. Even if you forget the surgeon's skill there is still the likes of ECMO (run full time by a perfusionist), EMG/NCS (an electrophysiologist) or the old classic, an anaesthetic machine (anaesthetist). Many of the UIs on these are, to the outside eye, downright janky.
Good tools usually have a beneficial tradeoff - it takes a minute or two to learn how to do it, but you have recurrent measureable gains in productivity after that. That includes closing Vim.
I wouldn't put it that blunt but I do agree. The problem are these nerds with seemingly infinite memory. It is almost impossible for them to make a UI for the rest of us.
I tried editing a txt document in vim one time. After gazing at the UI for much to long I had to ask for help because it wouldn't let me edit the txt.
I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
I could certainly learn some of vim's functionality but there would be very little disk space left to write the software. I'm seriously more productive using MS notepad or nano. I can totally see myself forget how to engage edit mode in a week or 2. I'm having visuals of picard ordering enterprise to engage
All i need is a shuttle!
The edit mode feels like a child safety feature where I'm the child.
Human children flying Vulkan space ships, think about it.
If non of this makes sense, that is the whole point.
>It is almost impossible for them to make a UI for the rest of us.
Have you considered that their tool is not necessarily made for you? You'd shudder at emacs yet there's still people there that really want it over vim and are more productive with it than most vim and vscode users.
>I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
it's 1 key. It's not intuitive by default tho that's very much true.
>They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
If you use a tool every day you're often expected to know a bit about it regardless of which one you use.
The previous poster compared it to a hammer and someone else mentioned a nailgun.
Similarly a an ax is simple but a chainsaw used more plenty by my father...but he knows how to replace and fix the chain, And even beyond that a nailgun and chainsaw are simple simple machines compared to the tooling you'll find in many workshops.
If you processed wood professionally you'd use room filling machinery instead to make boatloads of planks and whatnot in no time.
The thing is. Much of these issues one would encounter with em and things to know them are relatively simple and easy on their own... But seem difficult if you don't know. They're pretty easy to forget if you do it once. But if you've done it dozens of times you just know. Knowing these things doesn't impact the person's ability to learn other related things much. How a new kind of wood to cut behaves or whatever in the same way that remembering that new face and name doesn't obviously directly makes me forget my existing coworkers.
The key for learning a profession is to dump as much knowledge as possible into your 'muscle memory'. there are many operations in emacs and vi that i can do when i want to, but i might not be able to pull up the key sequence to tell someone. Like a musical instrument, the key is practise, practise, practise.
I don't feel like i have proficiency in a language until i have forced myself to speed run a few projects in it. The ideas are important, but it is the ingrained habits that keep the code clean and consistent.
I mean if you don't want to spend so much time studying a given profession, of course. But the neural positioning of generating this text, or transform this text' is different than the neural positioning of 'should this call to this new to me gRPC server be blocking? Timeout? Retries?'
The latter takes thorough focus. the former can be done by muscle memory with practise, and the limit is more on how many new things your fingers can learn in a month, the total of learned things can be quite high.
