The Rise of Microsoft Visual Studio Code(triplebyte.com)
triplebyte.com
The Rise of Microsoft Visual Studio Code
https://triplebyte.com/blog/editor-report-the-rise-of-visual-studio-code
326 comments
That was annoying me the entire time I was reading this, the entire article has an unspoken assumption that their interview process couldn't possibly be responsible for any discrepancy in the data.
I recall reading something to the effect that the most competent developers by Triplebyte's metrics used vim and Ruby on a Mac. That sounded too much like the typical hipster startup dev to be a coincidence, which got me wondering: is that really a snapshot of the best developers out there, or is it just what Triplebyte, hence their clients, are selecting for?
Well, what they hiring for, their questions in a specific language, how and who is evaluating the answers, the fact that a person is looking to work for them vs other companies are all biases. Nobody should try to extrapolate their results to the whole population of software engineers.
That said, Visual Studio is really on the rise. I used to think VSCode was late and could have never catch up with the Sublime's and Atom's ecosystem. So after trying it, I went back to my editor of choice. Lately though I went back to VSCode and I think it is pretty good out of the box and very good when you install the right plugins.
That said, Visual Studio is really on the rise. I used to think VSCode was late and could have never catch up with the Sublime's and Atom's ecosystem. So after trying it, I went back to my editor of choice. Lately though I went back to VSCode and I think it is pretty good out of the box and very good when you install the right plugins.
VSCode is only on the rise because alternatives are really bad. Meanwhile, it offers good defaults, and decent latency on modern hardware but for me it is just a glorified syntax highlighter.
VSCode becoming so popular should not tell us it is a great product, but that most modern alternatives suck.
VSCode becoming so popular should not tell us it is a great product, but that most modern alternatives suck.
So almost as if it's a relatively good product when compared with the alternatives
It is sad when all the alternatives are the same problems.
I want low latency and very very fast browsing through pages of code. Sublime text wasn't so bad, with support for VI bindings. But it did not offer more than just opening VI.
I lost most hope for innovation there.
I will stick to the terminal until something serious arrives.
I want low latency and very very fast browsing through pages of code. Sublime text wasn't so bad, with support for VI bindings. But it did not offer more than just opening VI.
I lost most hope for innovation there.
I will stick to the terminal until something serious arrives.
So no software should ever get any credit, just because they are doing a better job than their competitors?
I don't know if this counts, but it might, me and several friends and people I know who have all been doing Java for 10-15 years... are all writing typescript now. And using VSCode to do so.
Further, it looks like the questions are biased towards Ruby devs.
Interesting. With quick googling, I think these are the founders' GitHub pages?
Harj Taggar https://github.com/kwi
Guillaume Luccisano https://github.com/harj
Harj Taggar https://github.com/kwi
Guillaume Luccisano https://github.com/harj
[deleted]
I think the names and URLs are not matched up correctly. But other than that, yes.
Could you give some examples? I keep seeing annoying Triplebyte ads popping up and not sure what it is.
What kinds of examples are you asking for? Like specific parts of the interview?
I click on their ads every single time, using incognito mode, whenever I see them, just so that it costs them money. Their ads are completely deceitful in my opinion and nothing but clickbait.
There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me.
In my life:
- I'm committed to emacs for org-mode and LaTeX editing and daily use.
- I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging.
- I write serious python code in pycharm.
- I write serious c# in full blown Visual Studio
In my life:
- I'm committed to emacs for org-mode and LaTeX editing and daily use.
- I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging.
- I write serious python code in pycharm.
- I write serious c# in full blown Visual Studio
> This is a fantastic demonstration of why i exclusively use git from a command prompt...
Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you source control info inline are fantastic.)
Along with some nice features I've added, such as my 'git af' (add + fzf) shortcut[1][2], the commandline is very usable (don't have to 'git add' and type filenames manually).
[1] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8...
[2] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8...
Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you source control info inline are fantastic.)
Along with some nice features I've added, such as my 'git af' (add + fzf) shortcut[1][2], the commandline is very usable (don't have to 'git add' and type filenames manually).
[1] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8...
[2] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8...
Same here w/o fancy tooling around Git, but a couple of aliases.
I will refuse to use any Git tools or UIs, but the standard CLI, until the end of my career.
Besides that, my IDE/Editor is neither a build tool manager nor should it run my app from within an integrated console having specific settings. The projects people are going to inherit from me will always be editor-agnostic, the environment they run in will never depend on a certain setup that can‘t be documented clearly and they will always run within an isolated context, i.e. the project root.
I will refuse to use any Git tools or UIs, but the standard CLI, until the end of my career.
Besides that, my IDE/Editor is neither a build tool manager nor should it run my app from within an integrated console having specific settings. The projects people are going to inherit from me will always be editor-agnostic, the environment they run in will never depend on a certain setup that can‘t be documented clearly and they will always run within an isolated context, i.e. the project root.
I agree on part of that -- VSCode has a pretty good Node debugger, and you can run it with a listen hook (and therefore set it to run via a npm/yarn package.json script). Similarly, I feel like it's OK for an editor to run a script from the app in an integrated terminal, as long as that script is still accessible from a standard CLI.
Git is complex enough that I don't trust more complex operations (basically anything beyond push, pull, add, and checkout) to be handled by a GUI, but a GUI can make for a great code review tool.
Git is complex enough that I don't trust more complex operations (basically anything beyond push, pull, add, and checkout) to be handled by a GUI, but a GUI can make for a great code review tool.
God bless you.
Yesterday I came across a screencast I made in 2009 back when Xcode had separate windows for the console and the editor[8], and Interface Builder was a completely separate program external to Xcode. One of the things that stuck out to me was the silly "SCM" option in the NSOutlineView on the left side[2], which I had absolutely never touched. And I remembered from my more recent experiences using Xcode that its git integration is not very useful and overly simplistic.
So I started wondering why Apple would even want to add such a useless feature into an otherwise really powerful and useful editor, even back then in Xcode 3. And I imagined this scenario where they were brainstorming and someone higher up in the Xcode team was like "ok guys, I got word from above that 'source code' is becoming a big thing now, and we need to add it somewhere" and someone was like "how about the project navigation list?" and someone else maybe piped up "but it doesn't really fit hierarchically in the metaphor" and someone else was like "dude it's 4:30pm some of us have families to get back to can we just forget about the metaphorical inconsistencies?" and they just added it as an expandable item.
I use Xcode and VS Code ever day, and I absolutely never use the Git functionality in either of them. I tried both for a few weeks each, but absolutely nothing compares to Magit[4]. Not even command line. For git, Magit is the same secret weapon that pg claimed Lisp was for programming.
[2] https://i.imgur.com/DYJN12N.png
[4] https://magit.vc
[8] https://i.imgur.com/lXcGpDh.jpg
So I started wondering why Apple would even want to add such a useless feature into an otherwise really powerful and useful editor, even back then in Xcode 3. And I imagined this scenario where they were brainstorming and someone higher up in the Xcode team was like "ok guys, I got word from above that 'source code' is becoming a big thing now, and we need to add it somewhere" and someone was like "how about the project navigation list?" and someone else maybe piped up "but it doesn't really fit hierarchically in the metaphor" and someone else was like "dude it's 4:30pm some of us have families to get back to can we just forget about the metaphorical inconsistencies?" and they just added it as an expandable item.
I use Xcode and VS Code ever day, and I absolutely never use the Git functionality in either of them. I tried both for a few weeks each, but absolutely nothing compares to Magit[4]. Not even command line. For git, Magit is the same secret weapon that pg claimed Lisp was for programming.
[2] https://i.imgur.com/DYJN12N.png
[4] https://magit.vc
[8] https://i.imgur.com/lXcGpDh.jpg
I also very much related to this, the two exceptions I find awkward from the command line are:
* Doing partial adds with `git add -p`. I see the hunk it presents see what I want from it, but then sometimes have to go through several iterations of splitting, skipping etc.. A visual tool (even like the tool in vim-fugitive) is a huge improvement. At the end of the day I'm still looking at the staged diff before committing
* Looking at diff or blame logs. Once again these are super low risk for unexpected behavior, and for larger changes that span multiple files, I find the shiny editor features make it easy to see the context quickly.
There's a somewhat hidden gem in vanilla git which can be sometimes useful:
git gui
Even if I use git exclusively in the command prompt, I usually have a working copy where I edit files, and another copy that's read only where I switch branches without care, do the binary search bisect thing and so on.
I don't remember what happened for me to start doing this, but it saves so many headaches that I don't care.
All the graphic Git clients cause me panic. I have Sublime-Merge has a read only thing, because it shows diffs in a nice format. But I am still not ready to commit something from it.
I don't remember what happened for me to start doing this, but it saves so many headaches that I don't care.
All the graphic Git clients cause me panic. I have Sublime-Merge has a read only thing, because it shows diffs in a nice format. But I am still not ready to commit something from it.
Hint:
git add -iI use
git commit -a
That is not close to the same thing.
Since you're an Emacs user... just wanted to plug magit - it might make you change your mind about command-prompt-only git usage
I use Emacs mostly for magit.
P.S. VSCode has multi-cursor as well: https://code.visualstudio.com/docs/getstarted/tips-and-trick...
and emacs of course. https://youtu.be/jNa3axo40qM
> This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me.
This many times. I'll open SourceTree to view a large set of diffs or changes, but still drop back to the CLI to push/pull/rebase/commit/stash/etc... I know what git will do in those cases, and am a little wary of git UIs.
This many times. I'll open SourceTree to view a large set of diffs or changes, but still drop back to the CLI to push/pull/rebase/commit/stash/etc... I know what git will do in those cases, and am a little wary of git UIs.
Actually Eclipse's git UI is very practical. I use it whenever I'm developing somehting in Eclipse, however I still command line as much for other reasons.
OTOH, I despise heavily modified bash/zsh/whatever profiles which makes the environment non-portable. Extreme eye-candy in the console makes stuff harder for devs/admins who logs in to thousands of servers.
OTOH, I despise heavily modified bash/zsh/whatever profiles which makes the environment non-portable. Extreme eye-candy in the console makes stuff harder for devs/admins who logs in to thousands of servers.
> I paid for sublime so i will use it
I purchased Sublime when it was the least bad editor out there, but finally realized that I was suffering from the sunk cost fallacy. I still consider it the worst software purchase I've ever made, and it's also why I'm reluctant to pay a single buck for software nowadays.
I purchased Sublime when it was the least bad editor out there, but finally realized that I was suffering from the sunk cost fallacy. I still consider it the worst software purchase I've ever made, and it's also why I'm reluctant to pay a single buck for software nowadays.
I mean I use VS Code a lot more often, and PyCharm / JetBrains IDES moreso than I do Sublime Text but I wouldn't say it's the worst purchase. I bought a text editor that's got out of the box syntax highlighting for most languages and decent enough linting plugins to catch some of the syntax errors I may be about to miss.
I only wish Sublime Text were able to (out of the box) mount / SSH into any server like emacs does (using TRAMP). I'm finding myself using VIM lately mostly because it's a step up from nano which uses tabs, not sure how to tell it how to space things, nano is perfect for Go I suppose. I have to figure out how to configure VIM for spacing things properly though, but I mostly install Sublime Text on VM's I write code in.
I only wish Sublime Text were able to (out of the box) mount / SSH into any server like emacs does (using TRAMP). I'm finding myself using VIM lately mostly because it's a step up from nano which uses tabs, not sure how to tell it how to space things, nano is perfect for Go I suppose. I have to figure out how to configure VIM for spacing things properly though, but I mostly install Sublime Text on VM's I write code in.
I originally had two reasons why I bought Sublime. The primary one was that it felt like Vim with everything configured out of the box. Another reason was that ST2 had long outstanding bugs that were already fixed in the ST3 development version, which was made available to paying customers only, and it felt like a good idea to support the development.
Then came 2014 and it started to look like the Sublime developer had taken a hiatus. The timing was really bad as ST2 still had showstopper issues (for me) that were fixed in ST3, which in turn had another bunch of unfixed bugs. Meanwhile Atom was released and it got its bug fixes and new features regularly, even though it was and still is really slow. I had to choose between two borderline unusable and one functioning but heavy editor. With a heavy heart I had to abandon an editor that I had valued at 70 dollars, which at that time was also the largest sum I had ever paid for software.
As soon as VS Code started to gain traction, I made the switch. For some reason it felt and still feels much snappier, even though both Atom and it are built on Electron and have approximately the same features.
When not writing code or LaTeX documents, I'm editor and OS agnostic. Often you just have to make do with whatever an esoteric system offers.
Then came 2014 and it started to look like the Sublime developer had taken a hiatus. The timing was really bad as ST2 still had showstopper issues (for me) that were fixed in ST3, which in turn had another bunch of unfixed bugs. Meanwhile Atom was released and it got its bug fixes and new features regularly, even though it was and still is really slow. I had to choose between two borderline unusable and one functioning but heavy editor. With a heavy heart I had to abandon an editor that I had valued at 70 dollars, which at that time was also the largest sum I had ever paid for software.
As soon as VS Code started to gain traction, I made the switch. For some reason it felt and still feels much snappier, even though both Atom and it are built on Electron and have approximately the same features.
When not writing code or LaTeX documents, I'm editor and OS agnostic. Often you just have to make do with whatever an esoteric system offers.
> When not writing code or LaTeX documents, I'm editor and OS agnostic. Often you just have to make do with whatever an esoteric system offers.
If only more were sanely tech agnostic. I feel the same way, I try to use JetBrains tools if possible, if low on memory, then Sublime, VIM or Emacs (Somewhat Nano / ne) work for me.
If only more were sanely tech agnostic. I feel the same way, I try to use JetBrains tools if possible, if low on memory, then Sublime, VIM or Emacs (Somewhat Nano / ne) work for me.
Why do you think Sublime Text is the worst software you have purchased? I use it every day as my main text editor and i am very satisfied.
See the reply to the sibling post.
In any case, what works for you might not work for other people. We're also talking about four–five years old issues here.
In any case, what works for you might not work for other people. We're also talking about four–five years old issues here.
> I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging
These days pretty much every serious editor has multiple cursors, including Visual Studio Code.
These days pretty much every serious editor has multiple cursors, including Visual Studio Code.
had to look up "multiple cursors" and it looks like it's the same as "column mode" which has been around in MS editors forever?
It's not column mode in Visual Studio Code
https://code.visualstudio.com/docs/editor/codebasics#_multip...
Indeed, I've been missing out!
[deleted]
dude. you have been missing out.
amen
people look at me like I'm an old crazy dude because I don't use a git UI or eclipse, or intellij, or from sublime. Git already has plenty of quirks, adding another layer of unknown on top of it is a no-go
people look at me like I'm an old crazy dude because I don't use a git UI or eclipse, or intellij, or from sublime. Git already has plenty of quirks, adding another layer of unknown on top of it is a no-go
I've started using VSCode for git push/pull/branch and staging. This is what I use git for 99% of the time anyways and since they are simple commands, triggering them from VSCode is faster than falling back to CLI.
Staging/diffing is especially convenient with VSCode. `git add -p` used to be my most-used command, but VSCode just makes the process easier.
Staging/diffing is especially convenient with VSCode. `git add -p` used to be my most-used command, but VSCode just makes the process easier.
If you stage things often enough, `git add -u` might be enough. It's pretty much what I use all the time, aside from the few times I do `git add -up`.
My most famous quote in my work Slack is: "git already has a luxurious client! it’s called git and has lots of shinies."
While I agree with this in most cases, visual merge is a huge deal.
git mergetool will spawn the mergetool of your choice, anything from kdiff3 to vimdiff.
Which is weird because with all of its inconsistencies, git must have been designed with the idea that someone would build a sensible shell over top of it. I can't imagine Linus expected people to interact directly with git when he built it.
git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems.
I use multiple IDEs/editors, and they all handle git differently. It doesn't make sense to learn yet another N sets of quirks.
I use multiple IDEs/editors, and they all handle git differently. It doesn't make sense to learn yet another N sets of quirks.
> git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems.
Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not.
That said, I still use CLI precisely because I don't trust other software to make sensible abstractions on top of it, given that foundation is so inconsistent. Besides, those CI scripts only know git cli...
Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not.
That said, I still use CLI precisely because I don't trust other software to make sensible abstractions on top of it, given that foundation is so inconsistent. Besides, those CI scripts only know git cli...
> Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not.
> well known set of problems
that's precisely the well know set of problems. You learn them once, apply on every console. If each UI decides to overcome them differently, you end up with N+1 different behaviors.
I'd rather have only one set if inconsistent commands, than 3.
edit:formatting
> well known set of problems
that's precisely the well know set of problems. You learn them once, apply on every console. If each UI decides to overcome them differently, you end up with N+1 different behaviors.
I'd rather have only one set if inconsistent commands, than 3.
edit:formatting
Consistent in time. Those warts haven't changed much in the 7 or 8 years that I've been using git.
this is precisely the case: http://www.gelato.unsw.edu.au/archives/git/0504/0873.html
OT: that's a blast from the past - http://www.gelato.unsw.edu.au/
Heh. As an "old dude" I'd assume that anybody using git directly would be a "young dude" who's been using git all their programming life.
I managed to commit node_modules folder to github using VS Code git integration. Luckily it was on a smaller test project. My fault but there was a UI failure.
All I did was press Commit which apparently decided to stage and commit everything under the root folder.
It didn't do this in other projects so who knows what was different.
This is how credential files must get committed to github every day.
If VS Code is going to be smart about so many other things, then there should be some sort of warning for major code affecting changes.
You are about to push 5000 files to master repo inluding some that appear to be widely used libraries, are you sure that is what you want ?
All I did was press Commit which apparently decided to stage and commit everything under the root folder.
It didn't do this in other projects so who knows what was different.
This is how credential files must get committed to github every day.
If VS Code is going to be smart about so many other things, then there should be some sort of warning for major code affecting changes.
You are about to push 5000 files to master repo inluding some that appear to be widely used libraries, are you sure that is what you want ?
> All I did was press Commit which apparently decided to stage and commit everything under the root folder
If you don't have anything staged and hit Commit, it will show a prompt asking if you want to commit everything that's been changed. It sounds like you hit 'yes' on this prompt by mistake.
If you don't have anything staged and hit Commit, it will show a prompt asking if you want to commit everything that's been changed. It sounds like you hit 'yes' on this prompt by mistake.
To each their own. I've used CLI git only for a decent amount of time but VSCode's git diff view is fantastic and effortless to use. Their interface for staging files and making commits is excellent and combined with the ease of viewing local changes, it makes it very easy to ensure that commit messages are well documented and accurate. Same goes for handling merge conflicts.
I still use the CLI to push/pull/branch/merge, etc just to have total control, but staging files, viewing diffs and making commits are a lot more annoying in the CLI.
I still use the CLI to push/pull/branch/merge, etc just to have total control, but staging files, viewing diffs and making commits are a lot more annoying in the CLI.
> fantastic demonstration of why i exclusively use git from a command prompt
What's described in that github issue happened to me as well the first time I used git via Visual Studio. I normally don't do that, but something told me to make a zip of everything before using git in VS. So that saved me big time.
Why in the world are the deletions not pointed to the Recycle Bin??? That's what it's there for.
What's described in that github issue happened to me as well the first time I used git via Visual Studio. I normally don't do that, but something told me to make a zip of everything before using git in VS. So that saved me big time.
Why in the world are the deletions not pointed to the Recycle Bin??? That's what it's there for.
Agreed, it's sort of surreal that nobody in any of the issue threads admitted that was a good solution.
It’s not a good solution at all; it makes no sense in the context of source control because the repository IS the undo button, and copying discarded changes to the recycle bin would just add a lot of incoherent duplication into the recycle bin for no reason. Not to mention that’s not how git works, so it’d have to be added as a git extension, and you’d end up with people who actually know how their source control tools work feeling confused and annoyed that their editor is changing how their familiar tools work.
I mean, if you point software you don’t understand at work that’s not backed up you shouldn’t be shocked if it does something you don’t like
I mean, if you point software you don’t understand at work that’s not backed up you shouldn’t be shocked if it does something you don’t like
> and multiple cursors everywhere is a boon for quick and dirty data munging.
VSCode has this. Hold down Command on Macs (probably Ctrl on Windows/Linux) and click. You can also select "next similar word" with command-D so you can quickly change all instances of a word to another word.
VSCode has this. Hold down Command on Macs (probably Ctrl on Windows/Linux) and click. You can also select "next similar word" with command-D so you can quickly change all instances of a word to another word.
Ctrl+Shift+L will select all instances of the highlighted term in one shot. Ctrl+D , as you mentioned, is useful for progressively selecting the highlighted phrase within the file.
Awesome, TIL about Ctrl-Shift-L!
I am much the same. I have stickers for IntelliJ (as a stand in for all JetBrains IDEs), Emacs and Vim on my laptop because each has a different use case and preferred language. I even have Atom, Sublime and others installed and use them on rare occasions when they have plugins that are useful for a task at hand.
I also exclusively use the command line for source control (of which I use at least four, but mostly git and hg). I just do not trust IDEs to do the right thing, although JetBrains does get close (but my colleague devs hate the properly pruned .idea in the repos).
I also exclusively use the command line for source control (of which I use at least four, but mostly git and hg). I just do not trust IDEs to do the right thing, although JetBrains does get close (but my colleague devs hate the properly pruned .idea in the repos).
I use TortoiseHg for Hg. Source Tree for git (though I honestly don't like it very much, and often use hg-git to just work with git from TortoiseHg). Sublime for text editing; and agreed on the multiple cursors and great regexing - fantastic for quick and dirty munging indeed. I use VS for writing C#, creating SQL databases, and a myriad of other functions that would take too long to get into. LinqPad for quick experiments or writing up some quick scripts I need to run rarely.
I've had best results decoupling my tools, so I use a separate git client (in my case, Git Tower). You can also add things like database clients to VSC, but similarly I use Datagrip etc.
[deleted]
I do command line git as well because I am bouncing between IDEs and dont want to learn the differences in little features of each IDEs source control ui.
Since you mention both using git directly from the command line and Emacs, have you tried magit?
multi cursor is pretty much a basic feature in all modern text editors these days.
> Engineers who use Go are also especially strong. If you know why, please let me know.
Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake.
It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interest to spend time learning something unnecessary.
Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake.
It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interest to spend time learning something unnecessary.
This is what Paul Graham calls the Python Paradox; namely that in 2004, when Python jobs were relatively more rare, you could find smarter Python engineers than Java engineers for any given project.
"[I]f a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job."
http://www.paulgraham.com/pypar.html
"[I]f a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job."
http://www.paulgraham.com/pypar.html
I think that's exactly it. The problem is when these articles come out and everybody try to learn Go and use VS Code so they think can become smarter or at least being perceive as such :-P
Both of these are still just very roundabout ways of telling yourself you're awesome because of whatever mildly unusual thing you think you might be doing.
And this comment is just a subtextual justification for making sure you still feel valued for not doing anything unusual.
This could go round and round. The point is that there SEEMS to be a correlation with people who learn things for the sake of learning them and folks who do well at exercises that test for adjacent skills.
This could go round and round. The point is that there SEEMS to be a correlation with people who learn things for the sake of learning them and folks who do well at exercises that test for adjacent skills.
you still feel valued for not doing anything unusual
I didn't really express any thoughts or feelings about doing unusual things, real or perceived. Doing unusual things can be great! Telling yourself you are awesome can also be great! I do think, though, that the type of thought expressed in the "The Python Paradox" and related writings (say, the bit about blub language programmers) is pretty lousy. It was lousy then and has aged even more poorly.
I didn't really express any thoughts or feelings about doing unusual things, real or perceived. Doing unusual things can be great! Telling yourself you are awesome can also be great! I do think, though, that the type of thought expressed in the "The Python Paradox" and related writings (say, the bit about blub language programmers) is pretty lousy. It was lousy then and has aged even more poorly.
One day you wake up and have your own custom firmware on your hacked together laptop which is running a Linux that's using three different package managers on top of custom built kernel and x.
Each step seemed like a good idea but when taken together you wonder what when wrong and when.
Each step seemed like a good idea but when taken together you wonder what when wrong and when.
He he, nice contrarian opinion. Me like, mucho (and gracias). The other side may also be true, but this one can be too. Folks on here and elsewhere (juveniles of all ages), time to learn about the age-old saw that there is more than one way of looking at it / different strokes for different folks / circumstances alter cases / get out of your echo chamber / filter bubble / etc.
"Because there is almost no reason to learn Go."
No, that's not it. It's that if you can only learn one programming language, Go is not a very good choice, so those who learn Go are almost always multilingual ("lingual" as in programming languages, not natural languages). Python and JavaScript are Swiss Army knives with outstanding ecosystems that make them excellent choices if you can only afford one tool. There are plenty of reasons to learn Go but, as a more specialized tool, it makes a better component of a nice toolset than a solitary multitool.
My anecdotal experience says that 1) most programmers are monolingual, 2) almost all Go programmers are multilingual, and 3) the average multilingual programmer is a better programmer than the average monolingual programmer for various reasons, so the average Go programmer is better than the average programmer. And, by that logic, the average Rust, Haskell, Erlang, Lisp, etc., programmer would be, too.
No, that's not it. It's that if you can only learn one programming language, Go is not a very good choice, so those who learn Go are almost always multilingual ("lingual" as in programming languages, not natural languages). Python and JavaScript are Swiss Army knives with outstanding ecosystems that make them excellent choices if you can only afford one tool. There are plenty of reasons to learn Go but, as a more specialized tool, it makes a better component of a nice toolset than a solitary multitool.
My anecdotal experience says that 1) most programmers are monolingual, 2) almost all Go programmers are multilingual, and 3) the average multilingual programmer is a better programmer than the average monolingual programmer for various reasons, so the average Go programmer is better than the average programmer. And, by that logic, the average Rust, Haskell, Erlang, Lisp, etc., programmer would be, too.
> My anecdotal experience says that 1) most programmers are monolingual,
This surprises me as I've never worked on a nontrivial system that's also a monolingual system.
There's nearly always another language to use to get the job done, whether for configuration, scripting/automation, or because backends and UIs are written in different languages, especially for internet-based software.
This surprises me as I've never worked on a nontrivial system that's also a monolingual system.
There's nearly always another language to use to get the job done, whether for configuration, scripting/automation, or because backends and UIs are written in different languages, especially for internet-based software.
There's nearly always another language to use to get the job done
Sure, but in most cases programmers spend most of their time only in one 'part' of the system and only really have to know the language that part of written. In general it doesn't matter if the back end server is written in Lisp, Java or APL, as long as it talks to my part of the system in the way it's supposed to.
Sure, but in most cases programmers spend most of their time only in one 'part' of the system and only really have to know the language that part of written. In general it doesn't matter if the back end server is written in Lisp, Java or APL, as long as it talks to my part of the system in the way it's supposed to.
> in most cases programmers spend most of their time only in one 'part' of the system
Perhaps that's a reflection of the structure of the organizations they work in.
Anyways, the other cause of multilingualism is switching jobs, projects, or problem spaces. All three of those often involve a language switch.
Perhaps that's a reflection of the structure of the organizations they work in.
Anyways, the other cause of multilingualism is switching jobs, projects, or problem spaces. All three of those often involve a language switch.
Isn't most software rather trivial? Like in copying strings around.
Go is a language designed to take CS college graduates to productive engineers at Google with as little fuss as possible. Considering it was designed for an organization in the scope of Google, it's less likely to be the best option for something like a startup, small business, or even a medium size business.
I feel like you should spend some time with Go. If I were building a startup, I would probably choose Go for core infra for being able to move quickly as a developer and write incredibly performant code with about as much mental overhead as most dynamically typed languages.
Anecdotally, I've seen it replace Java in quite a few small and medium sized established companies.
Anecdotally, I've seen it replace Java in quite a few small and medium sized established companies.
I feel like Python is your pepperoni pizza can't go wrong option for almost anything.
Go feels similar but younger. I love languages with big standard libraries. Just need their package management story to settle down for a while.
There's something wonderful about a language being so popular and around for so long that there's plenty of resources and answers on just about anything. I think that's a core part of what I'm missing from Go.
Go feels similar but younger. I love languages with big standard libraries. Just need their package management story to settle down for a while.
There's something wonderful about a language being so popular and around for so long that there's plenty of resources and answers on just about anything. I think that's a core part of what I'm missing from Go.
Python can go wrong for large codebases. There are exceptions, of course, but if I focus on the consensus: large code bases in a dynamic language have an anecdotally significant likelihood of becoming unmaintainable. It's a glass ceiling that almost everyone I've met, who has done serious work with a dynamic language, has encountered.
There are ways to deal with it, but it requires rigorous discipline, and resisting Python's dynamic siren call earlier on in the process.
Golang naturally guides you into a style of programming which scales. You're not fighting the language (or your own inclinations) to avoid getting entangled later on.
Everything has exceptions†, you can shoot yourself in the foot with anything, yes. But, reasonably, it's about the relative struggle to end up in a similar place. Which is higher for Golang initially, but higher for Python later on.
Not trying to turn this into a Python vs Go thread; they both have their place. But Python can definitely go wrong, in an area significant to many people.
† Except Go... T_T
There are ways to deal with it, but it requires rigorous discipline, and resisting Python's dynamic siren call earlier on in the process.
Golang naturally guides you into a style of programming which scales. You're not fighting the language (or your own inclinations) to avoid getting entangled later on.
Everything has exceptions†, you can shoot yourself in the foot with anything, yes. But, reasonably, it's about the relative struggle to end up in a similar place. Which is higher for Golang initially, but higher for Python later on.
Not trying to turn this into a Python vs Go thread; they both have their place. But Python can definitely go wrong, in an area significant to many people.
† Except Go... T_T
Most of the workarounds seem to boil down to de facto static typing in function signatures. That is, using annotations / rigidly formatted comments to provide the type information necessary for IDE support.
Yeah I'm inclined to agree the more I think about it.
If Go adds generics and a smoother method of doing error handling, I could see it eventually taking Python's place. It already is doing so to an extent, but with those features plus everything else it can do better than Python, it'd be tough to beat. 95% of my programming is in Python, and I honestly don't really enjoy coding in Go that much, but with those changes I could see myself switching.
Same. 99% of my back-end and robot code is Python. Maybe this is a grass is always greener kind of thing but I'm hitting projects of a size where I miss static typing.
I will say that asyncio is amazing and really solves concurrency for me. But Go looks like you also get parallelism without a lot of work.
I will say that asyncio is amazing and really solves concurrency for me. But Go looks like you also get parallelism without a lot of work.
Asyncio is good but it will not give you true parallelism: asyncio still uses the GIL, on a single thread
Yep. Concurrency is not parallelism. But a lot of the time it's just not necessary.
On the other hand if Python community had more love for PyPy, to follow up on JavaScript and Julia footsteps, maybe that wouldn't be even an issue.
Go targets a number of performance sensitive systems programming contexts where Python would be completely inappropriate.
Its beauty is that there is so little to it. You don’t need StackOverflow to discover/debug a clever way of expressing something because there is no clever way. It feels limiting until you learn the idioms.
Package management has indeed been extremely painful, particularly in the Glide era, but Dep and VGO are both solid.
Its beauty is that there is so little to it. You don’t need StackOverflow to discover/debug a clever way of expressing something because there is no clever way. It feels limiting until you learn the idioms.
Package management has indeed been extremely painful, particularly in the Glide era, but Dep and VGO are both solid.
Python is wrong for anything performance sensitive (unless the performance part is already written in C/C++, like TensorFlow).
Performance sensitivity is a rather relative line, I understand your point but I’ve heard people argue that C was the performance sensical choice as opposed to C++, or assembly rather than C. I love python but I wouldn’t use it for everything. I really enjoy Go but the use cases for me are smaller than most people I know that use Go daily. At work we have to use Go and I’ve had to make the argument to use JVM for some services and Erlang/Elixir for other use cases. I could’ve done everything in Go, but it really felt more dogmatic than pragmatic
> I would probably choose Go for core infra for being able to move quickly as a developer
At the company I used to work at it took nearly a 1000 lines to replace an 80 line bash script. So I can't help but laugh at this statement.
At the company I used to work at it took nearly a 1000 lines to replace an 80 line bash script. So I can't help but laugh at this statement.
I've helped port some bash-based CLI tools to Go. The amount of code produced was pretty similar, just some overhead for typing and adapting some of the `awk` and `sed` functionality to be self-contained in the program. What kind of stuff was this 80 line bash script doing that resulted in over 12.5 times more code?
[deleted]
[deleted]
Since when LoC is a meaningful metric?
Since always but it depends on what you actually take into account.
More LOC means more opportunities for error, and more resources needed to review that code and more time required for a new developer to get familiar with the code base.
That said if you have 85 LOC vs 1000 it usually means that the 85 LOC “app” used a metric ton of external dependencies which are on their own a good source for problems.
When comparing apples to apples (as in both apps use dependencies equally) I don’t see how such delta can be caused by using a different language, even using assembly would likely not cause this much inflation.
More LOC means more opportunities for error, and more resources needed to review that code and more time required for a new developer to get familiar with the code base.
That said if you have 85 LOC vs 1000 it usually means that the 85 LOC “app” used a metric ton of external dependencies which are on their own a good source for problems.
When comparing apples to apples (as in both apps use dependencies equally) I don’t see how such delta can be caused by using a different language, even using assembly would likely not cause this much inflation.
How well did the bash script handle exceptions?
I can replace those 1000 lines with a bash script of 1 line that just calls the Go program ^_^
I really feel like learning Go and Rust made be better Java developer.
Wouldn't it be Rust or Haskell by this logic?
In that case, D developers should all be programming geniuses.
Because even less people use D than they use Go. :)
Because even less people use D than they use Go. :)
It's a good text editor, first and foremost. Compared to netbeans, eclipse, visual studio, even intellj idea in my opinion. The same thing that made textmate, then sublime text successful made VSC successful. I takes a few seconds to launch, even on my celeron machine with 2Gigs of RAM, it's relatively minimal and unlike intellj it doesn't appear to be analyzing my whole hard drive for hours for no reason...
the irony is that Microsoft did hire Eclipse creator to work on that product... hopefully it doesn't end up bloated. Having an open spec for language servers is also a smart move. While others have their proprietary, often non speced protocol, now any text editor can implement the same protocol and basically use any language server already developed.
So kudos for Microsoft, it's a great piece of engineering.
the irony is that Microsoft did hire Eclipse creator to work on that product... hopefully it doesn't end up bloated. Having an open spec for language servers is also a smart move. While others have their proprietary, often non speced protocol, now any text editor can implement the same protocol and basically use any language server already developed.
So kudos for Microsoft, it's a great piece of engineering.
> It's a good text editor, first and foremost. Compared to netbeans, eclipse, visual studio, even intellj idea
Have to disagree with VSC being better than Intellij. I find Intellij refactoring, debugging and autocomplete far ahead of VSC, especially when it comes to supporting leaser known features, or recently released language changes.
Have to disagree with VSC being better than Intellij. I find Intellij refactoring, debugging and autocomplete far ahead of VSC, especially when it comes to supporting leaser known features, or recently released language changes.
> Have to disagree with VSC being better than Intellij.
I didn't say it was a better than Intellij, I said it's a better text editor I'm not talking about integrated development, I'm talking about text editing.
I didn't say it was a better than Intellij, I said it's a better text editor I'm not talking about integrated development, I'm talking about text editing.
VSC and Intellij aren't the same thing. If you want better refactoring and debugging there are definitely plugins that do exactly that. Hard disagree on autocomplete, I've never run into a single situation where Intellij did it better.
Well, hard disagree on your hard disagreement, I've never ran into a situation where VSCode did better than Intellij/Webstorm :)
Often, the problem is the order of suggestions, it was magically almost always right on Webstorm and not as good on VSC
Often, the problem is the order of suggestions, it was magically almost always right on Webstorm and not as good on VSC
I tend to agree except for languages where the plugin ecosystem on VSC is still lacking. Ruby, for example. RubyMine is still much nicer by comparison, especially when working with Rails.
Actually I really do not like VSC resource consumption and performance. It feels more like eclipse than text editor but it does not offer as many features. If I want something fast and lightweight I reach for vim or sublime. But I do not care about start time as I leave all those program open all the time.
Agree.
All you need to do is just import a project like Chromium or Webkit... and try to navigate files/projects.
Sublime is really good for large projects.
Sublime is really good for large projects.
I still use Netbeans as my daily driver, but it's been in a death spiral. Now it's the Apache graveyard and will never get modern features like SASS.
Of all the IDEs I've been dabbling with for a replacement, I'm still deciding on Visual Studio Code or PHPStorm.
Of all the IDEs I've been dabbling with for a replacement, I'm still deciding on Visual Studio Code or PHPStorm.
VSCode is fast and it's certainly the best editor/IDE I've used since back when I was a Java dev using Eclipse back in 2006 or so.
But I recently opened up Sublime Text to compare some editor behaviour, and the difference in UI performance is astounding.
It's possible that VSCode has regressed a bit the last couple of years. It was always faster than Atom. But comparing it to Sublime shows that there are clear advantages to writing UI code in a natively compiled language. Sublime's widget drawing seems very well optimized.
VSCode has also become slower for me the last few years, simply from the load of extensions. I use the ESLint extension and the Go extension heavily, both of which parse code a lot. Neither is doing any sort of incremental parsing, so there's potentially a lot of churn. There's also some kind of indexing of symbols that happens in the background in the language server or in the extension. I sometimes have to kill the "Code Helper" process because it's sitting there consuming a whole core when idle.
Overall, VSCode is becoming increasingly closer to how I remember Atom, when I used it. I worry that it's slowly turning into Atom, performance-wise.
But I recently opened up Sublime Text to compare some editor behaviour, and the difference in UI performance is astounding.
It's possible that VSCode has regressed a bit the last couple of years. It was always faster than Atom. But comparing it to Sublime shows that there are clear advantages to writing UI code in a natively compiled language. Sublime's widget drawing seems very well optimized.
VSCode has also become slower for me the last few years, simply from the load of extensions. I use the ESLint extension and the Go extension heavily, both of which parse code a lot. Neither is doing any sort of incremental parsing, so there's potentially a lot of churn. There's also some kind of indexing of symbols that happens in the background in the language server or in the extension. I sometimes have to kill the "Code Helper" process because it's sitting there consuming a whole core when idle.
Overall, VSCode is becoming increasingly closer to how I remember Atom, when I used it. I worry that it's slowly turning into Atom, performance-wise.
> the difference in UI performance is astounding
I could not agree more. I've made numerous attempts to embrace the new hotness that is VSCode but I just cannot get over the performance. Yes, it has some cool features, the plug-in ecosystem is booming, and it sure looks pretty. But at the end of the day none of it is compelling enough for me to put up with the constant lag.
It's funny because after several of these experiments I have literally wondered to myself if I'm getting stuck in my ways or becoming a so-called "greybeard" due to my long term adherence to Sublime Text, but is constantly getting annoyed with how slow an editor is really a hallmark of old age? I'll wait for your web page to load, I'll wait for an ssh command to return. I will not wait for my bloody text editor. I have no patience whatsoever. Now god damn it NOW!
Another thing I wonder is how many of those VSCode users have simply never used anything better. If all you've ever known is an iPhone 5, you probably think it's pretty great - maybe you think that's just how phones are! This impression will be totally ruined of course when you try an iPhone X...
I could not agree more. I've made numerous attempts to embrace the new hotness that is VSCode but I just cannot get over the performance. Yes, it has some cool features, the plug-in ecosystem is booming, and it sure looks pretty. But at the end of the day none of it is compelling enough for me to put up with the constant lag.
It's funny because after several of these experiments I have literally wondered to myself if I'm getting stuck in my ways or becoming a so-called "greybeard" due to my long term adherence to Sublime Text, but is constantly getting annoyed with how slow an editor is really a hallmark of old age? I'll wait for your web page to load, I'll wait for an ssh command to return. I will not wait for my bloody text editor. I have no patience whatsoever. Now god damn it NOW!
Another thing I wonder is how many of those VSCode users have simply never used anything better. If all you've ever known is an iPhone 5, you probably think it's pretty great - maybe you think that's just how phones are! This impression will be totally ruined of course when you try an iPhone X...
I feel like if I took a serious shot at sublime I wouldn't be able to go back due to performance snappiness. Then I'd be miserable because I think vscode is superior in many other ways.
Which UI elements do you find slow?
The only things I find are slow are Language Server features. Which are just as slow in any IDE because they're using the same underlying application!
The only things I find are slow are Language Server features. Which are just as slow in any IDE because they're using the same underlying application!
I love VSCode and have moved to it from Sublime; mostly same shortcuts by default, inline debugging, extension ecosystem and blistering pace of development.
It's fast enough but Sublime blows it out of the water - especially for things to "Go To Symbol" where it works almost instantly whereas I'm constantly waiting for VSCode to stop spinning and give up and cmd-f search instead.
Also, I have to work with a lot of network-user-login RHEL6 boxes, and VSCode doesn't work on desktops that old.
It's fast enough but Sublime blows it out of the water - especially for things to "Go To Symbol" where it works almost instantly whereas I'm constantly waiting for VSCode to stop spinning and give up and cmd-f search instead.
Also, I have to work with a lot of network-user-login RHEL6 boxes, and VSCode doesn't work on desktops that old.
>especially for things to "Go To Symbol" where it works almost instantly whereas I'm constantly waiting for VSCode to stop spinning and give up and cmd-f search instead.
"Go to symbol" isn't implemented by the IDE though. Neither Sublime Text nor VSCode provide that feature.
Plugins do.
What you're probably experiencing is that Sublime Text tends to have less intelligent language servers. Which means they're faster, because they're not scanning your whole project, or because they're not using the official language server.
I've written my own language server so I know firsthand that any UI delay is entirely my fault, not VSCode.
"Go to symbol" isn't implemented by the IDE though. Neither Sublime Text nor VSCode provide that feature.
Plugins do.
What you're probably experiencing is that Sublime Text tends to have less intelligent language servers. Which means they're faster, because they're not scanning your whole project, or because they're not using the official language server.
I've written my own language server so I know firsthand that any UI delay is entirely my fault, not VSCode.
It seems strange to me to compare VSCode against PyCharm, IntelliJ, and Android Studio separately.
While PyCharm, IntelliJ, and Android Studio are distinct applications, I believe they share much of their code, UI, 3rd party plugins, and workflows for all being JetBrains language-flavored IDEs.
On the other hand, VSCode supports different languages through its extensions instead of having separate language-flavored applications like "VSCode Python", "VSCode Java", or "VSCode Android".
So I feel that reaching for IntelliJ vs. PyCharm vs. Android Studio is roughly equivalent to installing a particular set of extensions in VSCode. If you look at it that way, the data from the article seems to tell a different story - while VSCode has grown significantly in popularity, JetBrains IDEs seem to dominate in terms of overall usage (11.3% + 6.9% + 4.1% = 22.3% vs. VSCode's 16.8%).
On the other hand, VSCode supports different languages through its extensions instead of having separate language-flavored applications like "VSCode Python", "VSCode Java", or "VSCode Android".
So I feel that reaching for IntelliJ vs. PyCharm vs. Android Studio is roughly equivalent to installing a particular set of extensions in VSCode. If you look at it that way, the data from the article seems to tell a different story - while VSCode has grown significantly in popularity, JetBrains IDEs seem to dominate in terms of overall usage (11.3% + 6.9% + 4.1% = 22.3% vs. VSCode's 16.8%).
I didn't see any js or php specific stuff in their list, but have to assume phpstorm or webstorm might be in their 'other' category as well, pushing JB up to closer to 25%(?)
I use PyCharm and VSCode and I find that for python apps, PyCharm is much better. Lots of more features, easy to use commands, etc.
Having a dedicated IDE for a given language has it's pros.
However, I use VSCode for JS/HTML development, as it has a lot less clutter, than compared to other IDE's.
Having a dedicated IDE for a given language has it's pros.
However, I use VSCode for JS/HTML development, as it has a lot less clutter, than compared to other IDE's.
VSCode is fast, stable, and the plugin ecosystem really beats Sublime Text at this point. I was skeptical because Microsoft but it is hands down my favorite editor.
How can anyone say VSCode is fast, and then compare it to Sublime Text ? They are not even in the same order of magnitude.
VSCode is definitely fast enough for most uses cases, but I still wish it was as fast as Sublime Text, from Scrolling Frame-rate to response time.
VSCode is definitely fast enough for most uses cases, but I still wish it was as fast as Sublime Text, from Scrolling Frame-rate to response time.
Agreed. I use VS Code now because I needed syntax support for new es7+ and graphql.
But I miss sublimes speed it was unmatched, and the jump to symbol using @ or # in a file is worthless in vs code because it waits to calculate until you use it.
But I miss sublimes speed it was unmatched, and the jump to symbol using @ or # in a file is worthless in vs code because it waits to calculate until you use it.
I'm also skeptical of microsoft products, but they have come a long way since getting their new CEO. I've gained a lot of respect from them for better integration with non-windows platforms.
Someone said big companies are like aircraft carriers, they take a long time to change course and travel to the right destination, but if they do, once they are there they bring massive impact compared to more nimble and smaller sea vehicles.
MS developer tools have always been great, independently of whatever mess Windows gets itself into.
expect for a feature that keeps a lot of people on other editors (recordable macros) https://github.com/Microsoft/vscode/issues/4490
Agreed, it's bizarre that this feature is missing and apparently impossible to implement as an extension. It's been a fundamental feature of every serious programmers' editor for over 30 years!
I don’t use macros but it looks like I should tbh
Like it was said in this thread, as long as you have an editor that is built on something js-related like electron or node-js, it just cannot beat alternatives that are made in C++.
I've tried VSCode because I wanted to have UI breakpoints with GDB, I admit that vscode seems better than atom, but for performance I have my doubts.
I really don't understand why engineers choose to use JS to made a text editor. I know that js and the dom have enabled the web, but it's because there was nothing better, choosing js to do non-web stuff doesn't only sound silly, IT IS silly.
I've tried VSCode because I wanted to have UI breakpoints with GDB, I admit that vscode seems better than atom, but for performance I have my doubts.
I really don't understand why engineers choose to use JS to made a text editor. I know that js and the dom have enabled the web, but it's because there was nothing better, choosing js to do non-web stuff doesn't only sound silly, IT IS silly.
Everyone is on the argument that because you use C++ you'll always be faster.
I disagree, you get fast by using good datastructures and algorithms. Yes, for the same algorithm C++ may have some perf gains but it's so easy to shoot yourself in the foot. Visual Studio itself is written in Visual C++. It's slow and a memory hog.
Most folks who are not familar with JS don't understand the internals of V8. V8 does amazing things to compile the JS down to really fast bytecode. It builds hidden classes and structs just the way you'd write C++ and them compile them to machine code. There are many instances where the C++ code won't be much faster than the JS. In some cases naive C++ is even slower.
As for VSCode, it's a testament to show you can build very usable things by using the web as a platform. Chromium's blink's engine is fast if you know what you're doing.
Sublime is great, don't get me wrong, but VSCode's extension architecture gives it a leg up. It's so much easier to write a vscode extension than a sublime extension. Typescript gives the JS world a lot of sanity.
I disagree, you get fast by using good datastructures and algorithms. Yes, for the same algorithm C++ may have some perf gains but it's so easy to shoot yourself in the foot. Visual Studio itself is written in Visual C++. It's slow and a memory hog.
Most folks who are not familar with JS don't understand the internals of V8. V8 does amazing things to compile the JS down to really fast bytecode. It builds hidden classes and structs just the way you'd write C++ and them compile them to machine code. There are many instances where the C++ code won't be much faster than the JS. In some cases naive C++ is even slower.
As for VSCode, it's a testament to show you can build very usable things by using the web as a platform. Chromium's blink's engine is fast if you know what you're doing.
Sublime is great, don't get me wrong, but VSCode's extension architecture gives it a leg up. It's so much easier to write a vscode extension than a sublime extension. Typescript gives the JS world a lot of sanity.
> I really don't understand why engineers choose to use JS to made a text editor.
Not to sound snarky or anything, but because of their sheer numbers the argument is that it makes them a lot closer to the infinite amount of monkeys with an infinite amount of typewriters.
Not to sound snarky or anything, but because of their sheer numbers the argument is that it makes them a lot closer to the infinite amount of monkeys with an infinite amount of typewriters.
>I really don't understand why engineers choose to use JS to made a text editor.
-Much more beautiful and customizable UIs compared to native applications
-Easier cross platform development with Electron
Go for DDD as GUI for gdb.
Do you think it's a coincidence that some of the most used and loved desktop applications lately are written in JS/HTML? import_pkt_ws_btc_deribit_v2.py Could it be that it's extremely hard to do these kind of applications in traditional GUI frameworks?
Could it be that many JS devs don't bother to learn how GUI frameworks are able to do stuff where Web is still catching up with the 90's?
You're perhaps more snarky than necessary, but I think you're getting to the core of the problem.
The web has unfortunately made JS a very common first language, and created an army of people who know JS. Then rather than learn, say, C++ and Qt for building cross-plattform GUI, they stick to the language they know even though it leads to inferior results.
The web has unfortunately made JS a very common first language, and created an army of people who know JS. Then rather than learn, say, C++ and Qt for building cross-plattform GUI, they stick to the language they know even though it leads to inferior results.
One of my favorite things about VS Code is how usable it is with its default configuration, and how easy it is to customize to my liking. I found Atom and Sublime Text very frustrating in that regard.
Yep. I really like Sublime, and I probably still would be using it. I had it all set up to sync settings between my devices, with a nice theme, some handy plugins, and excellent syntax highlighters. But at some point I had both a new personal laptop and a new work computer. I had it on the back of my mind that I need to sort out my Sublime configuration again on both of these (which at the time included that weird dance to install Package Control). But then I already had VSCode working pretty well out of the box (including a perfectly good colour scheme), so my motivation to sort out Sublime became less and less until suddenly I was happy just using VSCode.
Interestingly, I found Atom to be much easier to customize. There are still things in VS Code I can't customize that I used to have in Atom.
That said, I've been on VS Code for a little more than a year now and it's grown on me.
That said, I've been on VS Code for a little more than a year now and it's grown on me.
To be clear, I meant easy in terms of how little I have to do the get it working to my liking. Atom might be easier to customize in general, but it requires more effort overall.
[deleted]
VS Code solves different problems then IntelliJ, PyCharm and Atom. I'm not sure this is a fair comparison. For example, I wouldn't ever code a full Java stack in VS Code. I'd go straight to IntelliJ.
Separately from being my JS IDE of choice, VS Code has for the most part replaced Notepad++. It's quite good at being a general purpose "heavyweight" text editor.
Has anybody written a Notepad++ to VS Code command translation guide?
I use Notepad++ for all sorts of text related things (cutting, sorting, making 100s of julennne phrases) but not as an editor.
If there was a cheat sheet of VS shortcuts I could ditch Notepad++ completely.
I use Notepad++ for all sorts of text related things (cutting, sorting, making 100s of julennne phrases) but not as an editor.
If there was a cheat sheet of VS shortcuts I could ditch Notepad++ completely.
VS Code has a printable cheatsheet of keyboard shortcuts that it prompts you to view when you first open the editor.
Also available here:
https://code.visualstudio.com/docs/getstarted/tips-and-trick...
I, too, am making the Notepad++ -> vscode move.
https://code.visualstudio.com/docs/getstarted/tips-and-trick...
I, too, am making the Notepad++ -> vscode move.
I don't see the point of ditching Notepad++. It's still an excellent text editor and it's more lightweight than VSCode. I use both and I'm very happy with it.
It's not about whether there's a point. Their functionality is close enough that it's entirely a matter of preference.
That's exactly what it's intended for, in my view. I still use Notepad++ for quick edits though, mostly because I am so used to it.
I switched from IntelliJ IDEA to VSCode for a massive legacy Java/Wildfly project. It started as an experiment, I figured I'd be back to IntelliJ within a week. I'm still using VSCode after a couple months now and I don't see a reason to go back to IntelliJ.
It starts and runs well, and has plugins for anything I might need. The day I run into something there isn't a plugin for, it's awesome to know that I could just make one to suit my need.
As far as negatives, VSCode has times where it gets hung up and intellisense is borked for a couple minutes, but I can usually just ignore the red squigglies until it catches up. I also don't yet feel as fast as I did in IntelliJ, IntelliJ has some really great keyboard shortcuts and I could jump around and work very quickly because of it. I'm hopeful this gap will close as I continue to learn and remember keyboard shortcuts in VSCode.
It starts and runs well, and has plugins for anything I might need. The day I run into something there isn't a plugin for, it's awesome to know that I could just make one to suit my need.
As far as negatives, VSCode has times where it gets hung up and intellisense is borked for a couple minutes, but I can usually just ignore the red squigglies until it catches up. I also don't yet feel as fast as I did in IntelliJ, IntelliJ has some really great keyboard shortcuts and I could jump around and work very quickly because of it. I'm hopeful this gap will close as I continue to learn and remember keyboard shortcuts in VSCode.
There’s a jetbrains (IntelliJ) flavored ide for basically everything - even c#! I prefer Rider for doing c# in Unity3D over VS or VSCode because it seems muc more performant and the vim plug-in is way better
I find Rider only way I can get performance and features of Resharper in a sane way. Visual Studio + Resharper feels very sluggish, while Rider doesn't have so much of problem with that. Also more convenient when opening more than one solutions simultaneously. (Which I do all the time!)
I actually enjoy using Rider on macOS over using Visual Studio for Mac with C#.
Sure, but Rider is a full-fledged IDE with years of dedicated development. Visual Studio for Mac is basically a skinned-over MonoDevelop still. It's getting better, but it's still nowhere near as mature and full-featured as Rider.
VS Code has something that JetBrains IDEs cannot match: Price.
For startups in developing countries $200 per seat is a lot of money... VS Code or Atom look amazing in comparison for $0
For startups in developing countries $200 per seat is a lot of money... VS Code or Atom look amazing in comparison for $0
You should talk to
Jetbrains if you are a startup. They have discounts and such.
Having good tools in a fast paced environment is the key to Keep things focused on the product. I’d argue it’s more critical in a startup than else where for that reason
Having good tools in a fast paced environment is the key to Keep things focused on the product. I’d argue it’s more critical in a startup than else where for that reason
VS code is a jack of all trades editor, obviously it's not going to be able to match more specialized editors
I use emacs for Java and Scala development with LSP quite successfully, and VS Code's support for language servers is as good as they come. Is it primarily debugging that's the impediment to switching for you?
While we're on the subject - not that many people are aware of it yet, but VS Code has a debugger protocol similar to LSP for pluggable IDE-agnostic debuggers.
https://microsoft.github.io/debug-adapter-protocol/
https://github.com/Microsoft/debug-adapter-protocol/blob/gh-...
I hope this takes off. Between it and LSP, pretty much any text editor can be an IDE with little effort.
https://microsoft.github.io/debug-adapter-protocol/
https://github.com/Microsoft/debug-adapter-protocol/blob/gh-...
I hope this takes off. Between it and LSP, pretty much any text editor can be an IDE with little effort.
Me too, the Spacemacs layers are really nice actually. Java and Scala ain't gonna keep me away from dired, macros, magit, org, nor my favorite shortcuts :D
Speaking of, I had a Spark lab for school and it was too powerful for my machine, so I ssh'ed into the school's computer and ran a spark-shell from there, in an emacs split. Then with a macro, it was easy to "send region" or "send buffer" to the ssh'ed spark-shell. I made a quick script for that actually, it was so convenient: https://github.com/tbinetruy/config/blob/master/spacemacs/sp...
And that's why I love my emacs, I can just do stuff like that so easily :D
Speaking of, I had a Spark lab for school and it was too powerful for my machine, so I ssh'ed into the school's computer and ran a spark-shell from there, in an emacs split. Then with a macro, it was easy to "send region" or "send buffer" to the ssh'ed spark-shell. I made a quick script for that actually, it was so convenient: https://github.com/tbinetruy/config/blob/master/spacemacs/sp...
And that's why I love my emacs, I can just do stuff like that so easily :D
I have some time off soon and there's a project I have planned that will use Scala. What LSP server do you recommend, and are you using it with lsp-mode or with eglot?
I'm using lsp-mode and the Eclipse JDT language server. lsp-java is great and the maintainer is very responsive to PRs and feedback.
For Scala I use Ensime at work and have been playing with metals at home. The latter is still very much under active development and you'll likely have to put up with Ensime's quirks for a complicated Scala codebase.
For Scala I use Ensime at work and have been playing with metals at home. The latter is still very much under active development and you'll likely have to put up with Ensime's quirks for a complicated Scala codebase.
I agree with the first two, but does VS Code really solve different problems than Atom?
IntelliJ has a huge head start in targeting Java. Right now it's my python & golang editor of choice.
Java on VS code is still kind of pain, which is too bad.
To me, VS Code and Typescript were made for each other.
Python is just a free bonus.
To me, VS Code and Typescript were made for each other.
Python is just a free bonus.
Frankly, I think we're seeing the results of the new era of Python paradox. Except it's not Python 3, it's TypeScript, VS Code, and React.
If you look at the education space, many of the deployments are either Chromebooks or iPads. Back in 2012, the "learn to code" sites (like Khan Academy or Code.org) ended up building their lesson plans around JavaScript.
https://johnresig.com/blog/introducing-khan-cs/
People who were in 3rd- and 4th-grade in 2012 would now be finishing up high school. Someone in 7th- or 8th- grade would have just finished a bachelor's, or maybe be looking for their second job after two or three years in the industry.
For these folks, TypeScript/VS Code/React would be a short jump from these learn-to-code-JavaScript-in-the-browser sandboxes.
As for Go... I suspect that's the set of people who can handle Google-scale software complexity. So either former Google employees, or people who are in the kubernetes ecosystem.
If you look at the education space, many of the deployments are either Chromebooks or iPads. Back in 2012, the "learn to code" sites (like Khan Academy or Code.org) ended up building their lesson plans around JavaScript.
https://johnresig.com/blog/introducing-khan-cs/
People who were in 3rd- and 4th-grade in 2012 would now be finishing up high school. Someone in 7th- or 8th- grade would have just finished a bachelor's, or maybe be looking for their second job after two or three years in the industry.
For these folks, TypeScript/VS Code/React would be a short jump from these learn-to-code-JavaScript-in-the-browser sandboxes.
As for Go... I suspect that's the set of people who can handle Google-scale software complexity. So either former Google employees, or people who are in the kubernetes ecosystem.
The "live shared coding" angle in VSCode makes it a great option in many areas where there's a need for it. People have been asking jetbrains for this for a decade, and there's nothing on the horizon as far as I can tell.
wow, never realized that was a supported feature. I must have glossed over that feature in that then feature release
https://code.visualstudio.com/blogs/2017/11/15/live-share
We use it in our distributed team and it works wonders for pair programming.
Ok I stopped reading when they started drawing graphs how well the people using certain editors fared better in their test as if the editor could have anything to do with it.
Later they did mention that they don't take into account the language or editor selection to make interview decisions.
They are just exploring the data they have acquired. May be they could have phrased that section differently.
They are just exploring the data they have acquired. May be they could have phrased that section differently.
Depending on the task and the familiarity of the user with the editor, it can make a big difference! As an extreme example, a good 80s programmer might work efficiently on a file in ed, but nowadays approximately no human could do that.
But their tests don't measure "how efficiently" the candidates edit files, do they?
OTOH, I've found that having a mastery of Vim helps me out a LOT in interviews where I get a computer to work at. I can actually type faster than I can think at this point, so I get to express my ideas pretty much as soon as they come to me, which allows me to "look more impressive", I guess.
They certainly shouldn't judge based on the choice of an editor or language, but 1) seeing that someone is very comfortable in any editor and any language shows they've been at it for a while, and being able to express the right answer quickly is almost as important as finding it at all.
They certainly shouldn't judge based on the choice of an editor or language, but 1) seeing that someone is very comfortable in any editor and any language shows they've been at it for a while, and being able to express the right answer quickly is almost as important as finding it at all.
Well that settles it, I’m off to program some Go code in Emacs.
I've told you guys before - my 10 year old son scored 'well above average' on their interview process. We live in the UK but they are still trying to recruit him. And no - he cannot write code.
My son has seen this post and points out that he not only uses unreal engine - to my complete surprise (and not just a little delight) - he has deployed some c++. I sent him to bed because it's late. Dad;s will know why.
The interview process reminded me of the theoretical exam for a drivers license. If you pick the option that sounds least crazy, you're fine.
I wonder if you just nailed being a prog
I'm not Microsoft's biggest fan (I switched away from .NET and their platforms a few years ago, switched to Mac, etc).
But I use VS Code, it really is a great little editor with a good ecosystem.
The JavaScript support pulled me in, but it's a pretty decent Rust environment now as well!
But I use VS Code, it really is a great little editor with a good ecosystem.
The JavaScript support pulled me in, but it's a pretty decent Rust environment now as well!
Another interesting angle on this is that VS Code is free (and open source), while Sublime is proprietary and (nominally) costs $80. I wonder how many people don't use Sublime because of the price? Atom is free too and never surpassed Sublime.
Expressedly, this is my opinion solely, with that said:
I stopped using Sublime and stopped recommending it not because of price (I actually prefer to pay for things when I can) but because the community plugins for my development workflow (PHP + Frontend) is...not great. I also found the distinct lack of API documentation to be frustrating (I'm not above making my own extensions and I very much like Python)
Visual Studio code at least has good front end tooling (The PHP extensions can't handle my large PHP projects, though I am tempted to try the a paid extension on this that I heard works well in Visual Studio proper, also, Twig support plain sucks. I'm not 100% certain if this is a limitation of VS Code or the Extension but it can't find my variables from the PHP files)
I've since moved to a combo of PHPStorm (my daily driver) and Visual Studio Code for Git Merges (I prefer the way you can handle it in VS Code) and doing other misc tasks that I don't want to fire up a PHPStorm instance for.
Same reason I never liked Atom. Tooling always seemed off somehow.
Side note? If you are going to pay for an editor, I recommend any JetBrains product offering.
I stopped using Sublime and stopped recommending it not because of price (I actually prefer to pay for things when I can) but because the community plugins for my development workflow (PHP + Frontend) is...not great. I also found the distinct lack of API documentation to be frustrating (I'm not above making my own extensions and I very much like Python)
Visual Studio code at least has good front end tooling (The PHP extensions can't handle my large PHP projects, though I am tempted to try the a paid extension on this that I heard works well in Visual Studio proper, also, Twig support plain sucks. I'm not 100% certain if this is a limitation of VS Code or the Extension but it can't find my variables from the PHP files)
I've since moved to a combo of PHPStorm (my daily driver) and Visual Studio Code for Git Merges (I prefer the way you can handle it in VS Code) and doing other misc tasks that I don't want to fire up a PHPStorm instance for.
Same reason I never liked Atom. Tooling always seemed off somehow.
Side note? If you are going to pay for an editor, I recommend any JetBrains product offering.
PhpStorm is by far the best editor. The slowness is a huge issue.
For frontend sublime offers a nicer experience. VCode feels slightly off but I do want to move over because it's free.
For quick development vim is perfect. If you need to make single page changes on multiple remote sites nothing is faster than dreamweaver 8. The designer/code split was always great no editor ever implemented anything to match.
For frontend sublime offers a nicer experience. VCode feels slightly off but I do want to move over because it's free.
For quick development vim is perfect. If you need to make single page changes on multiple remote sites nothing is faster than dreamweaver 8. The designer/code split was always great no editor ever implemented anything to match.
Be careful that's it's only open-source if you build it yourself or if you use VS-Codium (https://github.com/VSCodium/vscodium).
The VS-Code that everyone uses is under a Microsoft License and includes close source Microsoft telemetry (spyware?) and user data collection :
https://code.visualstudio.com/License/
The VS-Code that everyone uses is under a Microsoft License and includes close source Microsoft telemetry (spyware?) and user data collection :
https://code.visualstudio.com/License/
Not sure why you're downvoted. This is a concern. In my company, I downloaded VS Code to use it with F# for a toy project. But when I saw you cannot disable all data collection, I pretty much uninstalled it.
Most likely there is no IP risk, but I did not want to go through the trouble of finding out precisely what data is collected, and/or cross check with our legal department.
Plenty of people at the company do use VSCode, so I'm sure eventually IT will simply provide it to us through their own software repository (as they do for Visual Studio).
Most likely there is no IP risk, but I did not want to go through the trouble of finding out precisely what data is collected, and/or cross check with our legal department.
Plenty of people at the company do use VSCode, so I'm sure eventually IT will simply provide it to us through their own software repository (as they do for Visual Studio).
I work on VS Code. You can disable VS Code telemetry and even disable all built-in online services if you like. This is documented on the website [1]
However VS Code cannot block the extensions that you install from collecting their own telemetry. Even if use a version of VS Code built from source, an extension that you install could still collect telemetry of its own. Same applies to most software that allows third party plugins (unless they do some serious sandboxing/capability restriction, or only allow installing specifically vetted plugins)
[1]: https://code.visualstudio.com/docs/supporting/faq#_how-to-di...
However VS Code cannot block the extensions that you install from collecting their own telemetry. Even if use a version of VS Code built from source, an extension that you install could still collect telemetry of its own. Same applies to most software that allows third party plugins (unless they do some serious sandboxing/capability restriction, or only allow installing specifically vetted plugins)
[1]: https://code.visualstudio.com/docs/supporting/faq#_how-to-di...
It would be nicer if they made it clearer when they inform you during the installation. All I saw was that they collect, and I can turn the setting off, but it wouldn't turn off all collections.
Anyway, thanks for the info.
Anyway, thanks for the info.
I recently contributed VSCodium windows support, and IMO it's not too big of a different from the binaries that MS provides. The only few differences are the telemetry endpoints that are in the normal binary, that can be disabled through the setting, and some other MS specific branding
They state in the license that :
"You may opt-out of many of these scenarios, but not all, as described in the product documentation."
So it seems that not everything can be disabled in the settings ?
Maybe in practice they're not collecting too much sensitive data, but they could just distribute the FLOSS binary with a "Do you want to send telemetry data to Microsoft -Yes ? -No ?" at 1st lunch and if we say no then we have the guarantee nothing will be ever sent to them.
As far as I now this is what is done in Atom and I find it more clear and honest than a special license where "you can opt out but we still send data anyway".
I'm sure there no necessarily evil intentions, but still there this feeling that for once Microsoft is doing a great & successful Open Source software, they must find a way to put their own terms on it and collect user data.
"You may opt-out of many of these scenarios, but not all, as described in the product documentation."
So it seems that not everything can be disabled in the settings ?
Maybe in practice they're not collecting too much sensitive data, but they could just distribute the FLOSS binary with a "Do you want to send telemetry data to Microsoft -Yes ? -No ?" at 1st lunch and if we say no then we have the guarantee nothing will be ever sent to them.
As far as I now this is what is done in Atom and I find it more clear and honest than a special license where "you can opt out but we still send data anyway".
I'm sure there no necessarily evil intentions, but still there this feeling that for once Microsoft is doing a great & successful Open Source software, they must find a way to put their own terms on it and collect user data.
I've paid for Sublime, but I abandoned it for VS Code. For instance, the default Python setup - in particular its handling of virtualenvs, linters, and formatters - works pretty much out of the box. I was constantly fighting against the Sublime plugins to make them work halfway reasonably. Sublime is faster, but the lower mental overheard required to make VS Code work properly makes a much bigger difference to me than the price does.
What's the point investing time in learning a proprietary tool when the developers could take it away from you at any moment?
A lot of people I know who use Sublime never paid. In fact, I don't know anyone who paid for it IRL except myself.
If you don't pay, you only get a nag screen from time to time as you save. And cracks most likely exist if you want to get rid of it without paying.
BTW, I still use Sublime Text. I gave a try to VS Code and it is really great. It has most of the things that made me switch to Sublime (from Emacs), plus some more. The issue I had was performance. Sublime is generally more responsive for me, with less subsecond but still noticeable pauses.
If you don't pay, you only get a nag screen from time to time as you save. And cracks most likely exist if you want to get rid of it without paying.
BTW, I still use Sublime Text. I gave a try to VS Code and it is really great. It has most of the things that made me switch to Sublime (from Emacs), plus some more. The issue I had was performance. Sublime is generally more responsive for me, with less subsecond but still noticeable pauses.
Funny tho, that purchasing prompt is the only "feature" I'd missed from Sublime after switching to VS Code.
So I made one for it [1].
[1] https://marketplace.visualstudio.com/items?itemName=cottonh....
So I made one for it [1].
[1] https://marketplace.visualstudio.com/items?itemName=cottonh....
Edit: Disregard, I don't know wtf I'm talking about.
It's right there on the home page:
"Sublime Text is available for Mac, Windows and Linux. One license is all you need to use Sublime Text on every computer you own, no matter what operating system it uses.
Sublime Text uses a custom UI toolkit, optimized for speed and beauty, while taking advantage of native functionality on each platform."
Are we talking about some other sublime?
"Sublime Text is available for Mac, Windows and Linux. One license is all you need to use Sublime Text on every computer you own, no matter what operating system it uses.
Sublime Text uses a custom UI toolkit, optimized for speed and beauty, while taking advantage of native functionality on each platform."
Are we talking about some other sublime?
Shows me for not actually double-checking, I was pretty convinced. Is that a recent addition or is there another editor I'm thinking of?
No, it isn't. From the website:
Sublime Text is available for Mac, Windows and Linux. One license is all you need to use Sublime Text on every computer you own, no matter what operating system it uses.Wat?
"Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews?"
I think the Interview Pass Rates chart makes it clear that the answer is a statistical "Yes", at least for Emacs.
I think the Interview Pass Rates chart makes it clear that the answer is a statistical "Yes", at least for Emacs.
I've been almost exclusively an Emacs user since the turn of the millennium or so, even before I was a full-time professional programmer. I briefly tried out TextMate years ago, and I've tried out VS Code, but I stick to Emacs for day-to-day work, and the keybindings are pretty much hard-wired into me at this point.
At the same time, I hate and actively avoid typical tech interview processes, and I suspect my pass rate if I did a bunch of them would start out low and only grow after a while once I got used to "interview coding" (which is basically a separate skill from actual programming).
So I don't know why they see this effect. My first guess would be that it's a kind of survivorship bias; outside of the occasional splash of someone trendy inspiring some new users, using the classic Unix-y editors seems to correlate with older/more experienced programmers. Who, because they've managed to stick around as long as they have, probably can manage to get hired when they want or need to.
At the same time, I hate and actively avoid typical tech interview processes, and I suspect my pass rate if I did a bunch of them would start out low and only grow after a while once I got used to "interview coding" (which is basically a separate skill from actual programming).
So I don't know why they see this effect. My first guess would be that it's a kind of survivorship bias; outside of the occasional splash of someone trendy inspiring some new users, using the classic Unix-y editors seems to correlate with older/more experienced programmers. Who, because they've managed to stick around as long as they have, probably can manage to get hired when they want or need to.
Maybe it’s because the editor was taught to students at places like MIT, Berkeley, etc?
More probably because editors with a steep learning curve (emacs/vi) tend to select for people more willing to invest effort in learning.
The same can be said for Go when Go was relatively new. You learnt [Go^H^Hnew thing] because you thought it was interesting or wanted to play, not because you had to.
As a secondary effect, editors in the likes of emacs/vi require a different mindset compared to an IDE when programming on large projects. There's no question that all IDEs in general have an huge advantage for "all things discoverability" (from project layout to built-in doc).
I personally rely much more on documentation and memorization than autocomplete, despite autocomplete-like extensions being available to both emacs/vi for quite a while. There's a steep hill to climb when approaching large, new codebases when working this way, and it definitely doesn't pay off for quick fixes.
That being said, I used anything from IntelliJ, NetBeans to VSCode and when thinking about "good editor" the first thing that comes to mind is: zero latency. If your computer is slower than you, there's a problem somewhere.
The same can be said for Go when Go was relatively new. You learnt [Go^H^Hnew thing] because you thought it was interesting or wanted to play, not because you had to.
As a secondary effect, editors in the likes of emacs/vi require a different mindset compared to an IDE when programming on large projects. There's no question that all IDEs in general have an huge advantage for "all things discoverability" (from project layout to built-in doc).
I personally rely much more on documentation and memorization than autocomplete, despite autocomplete-like extensions being available to both emacs/vi for quite a while. There's a steep hill to climb when approaching large, new codebases when working this way, and it definitely doesn't pay off for quick fixes.
That being said, I used anything from IntelliJ, NetBeans to VSCode and when thinking about "good editor" the first thing that comes to mind is: zero latency. If your computer is slower than you, there's a problem somewhere.
I learned emacs in the late 1980's -- it is now an ingrained part of my brain. I hate when I have to use an IDE w a different editor -- at least most editors (and GUI components like browser textfields) respond to common emacs key-sequences.
I learned vim and with me is hitting :w<cr> all the damn time. Not to mention pressing <esc> to leave insert mode.
Had to use Android Studio/Eclipse for some time but it was so much harder that I kept trying to find ways to use vim even if I had to memorize or copy/paste package dependencies from Android.
I honestly wish I could use some of the most advanced refactoring tools from IDEs into vim but the way I edit is so ingrained that it's simply not worth it.
Had to use Android Studio/Eclipse for some time but it was so much harder that I kept trying to find ways to use vim even if I had to memorize or copy/paste package dependencies from Android.
I honestly wish I could use some of the most advanced refactoring tools from IDEs into vim but the way I edit is so ingrained that it's simply not worth it.
This feature makes switching from macOS to most other operating systems annoying, because I keep trying to ^E and realize it doesn't work…
I hit C-x C-s all the time in IDE's and I think sometimes it inserts weird invisible characters into the source -- fun.
You'll need to explain this...
Newspaper headline: "Emacs text editor makes people smarter."
> However, it seems that the average C# or Java engineer who goes through our process does less well than the average Ruby or Go engineer. I have no idea why.
Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
I have a theory on this. For most interview style coding problems (which tend to be algorithmic in nature), scripting languages such as python or ruby:
1) are less verbose
2) don't require worrying about typing
3) have really easy ways to manipulate strings, iterate, etc., which are often found in interview style problems
Java and C# have many advantages over python and ruby, but I think that they put you at an inherent disadvantage for many interview style questions which often require you to solve an algorithmic or data structure type problem in a limited amount of time [1].
[1] This doesn't explain why people using Go would tend to pass at higher rates, but since the Go community is comparatively much smaller, there could be other factors at play there.
1) are less verbose
2) don't require worrying about typing
3) have really easy ways to manipulate strings, iterate, etc., which are often found in interview style problems
Java and C# have many advantages over python and ruby, but I think that they put you at an inherent disadvantage for many interview style questions which often require you to solve an algorithmic or data structure type problem in a limited amount of time [1].
[1] This doesn't explain why people using Go would tend to pass at higher rates, but since the Go community is comparatively much smaller, there could be other factors at play there.
My job involves interviewing many engineering candidates, and I see the issue with typing all the time. A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose, meaning there are more lines of code which means more small problems that can arise. That matters greatly in a short, time-boxed context.
> A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose
I don't think that the fact that it's statically typed is the problem. For example, I don't believe a competent Rust, Go, or Haskell dev would be at a disadvantage due to static typing, but rather the opposite.
I don't think that the fact that it's statically typed is the problem. For example, I don't believe a competent Rust, Go, or Haskell dev would be at a disadvantage due to static typing, but rather the opposite.
As someone else who's run a lot of interviews including tech exercises (as much as I hate the typical way they're done, I haven't been able to eliminate them everywhere I've worked), I have the same experience as the parent commenter. Yes, even with "good" statically-typed languages like $YOUR_FAVORITE_LANG_HERE.
Candidates using those languages can often sketch out the right algorithm and the structure of what the program would look like, but under time pressure have trouble producing something that actually will compile and run properly (and as much as I want "showed they got the right algorithm and how to do it" to be a pass, it isn't always). The "executable pseudocode" nature of the popular dynamic languages is a big advantage there.
It's definitely even worse for C#/Java style languages (though C# is better than it used to be), because of all the heavyweight design pattern stuff you need to implement to do things that are just natural idioms in the dynamic languages. But it's something I've seen happen in a broad range of static languages.
Candidates using those languages can often sketch out the right algorithm and the structure of what the program would look like, but under time pressure have trouble producing something that actually will compile and run properly (and as much as I want "showed they got the right algorithm and how to do it" to be a pass, it isn't always). The "executable pseudocode" nature of the popular dynamic languages is a big advantage there.
It's definitely even worse for C#/Java style languages (though C# is better than it used to be), because of all the heavyweight design pattern stuff you need to implement to do things that are just natural idioms in the dynamic languages. But it's something I've seen happen in a broad range of static languages.
In my experience, static typing, in general, puts you at a disadvantage. It obviously varies between companies, but in scenarios like HackerRank where you have a fixed amount of time and either pass/no pass, dealing with types can be a real obstacle.
I am a C# dev who plays with python in my spare time.
In coding interviews, some interviewers want compiler approved code. That's a lot less writing with python than with C#. The problem is I'm just not as confident with python as I am with C#. If you want compiler approved board code then I've got to write it with C# and not python.
In coding interviews, some interviewers want compiler approved code. That's a lot less writing with python than with C#. The problem is I'm just not as confident with python as I am with C#. If you want compiler approved board code then I've got to write it with C# and not python.
Maybe because with Go, there's less ways to skin a cat compared to each of the other languages?
Less expressive language - just hammer out code worry free about being judged on method or code style?
> > However, it seems that the average C# or Java engineer who goes through our process does less well than the average Ruby or Go engineer. I have no idea why.
> Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
> Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
Something I've noticed over time is that a good chunk of the people not too enthusiastic about their work tend to gravitate towards the enterprisey stuff like java, C# or VB while the more enthusiastic may end up in embedded, research or low level code like the guts of an OS or database.
I wonder ....
> Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?
> Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
Something I've noticed over time is that a good chunk of the people not too enthusiastic about their work tend to gravitate towards the enterprisey stuff like java, C# or VB while the more enthusiastic may end up in embedded, research or low level code like the guts of an OS or database.
I wonder ....
I suspect it's because most Java and C# engineers are "enterprise" engineers who work on mostly CRUD applications. Go and Ruby would be more aligned for a startup. Given that TripleByte's interview process is more technical and computer science oriented, I'm not surprised they score less. It's mainly about the types of problems you solve at work and how well you keep technical knowledge fresh.
I think the author is saying they have no idea why C# and Java devs are worse on average than Ruby and Go devs. I'm sure they know the specific reason those devs fail, but are trying to understand the more general trends that lead to higher rates of failure. I would guess that this is another instance of the python paradox (http://www.paulgraham.com/pypar.html).
We’ve been a C# house since .net 2.0 and having recently moved a lot of our things to first JS and then python I think it’s the tooling.
Visual studio does a lot of things for you without a CLI. Want to deploy? Right click on your project and do the UI wizard for it. I mean, even nuget has a gui.
On top of that C# comes with a ton of easy to use features from its library. Like AD integration is just a library that gives you everything you need, at least until it doesn’t and you have to write your own bits and things get hard, but until then everything is easy and it’s much easier than using an open source library for it. I think any C# programmer could use its basic functionality from VS without ever looking at its documentation, and while Django and flask integrates with AD as well, you can’t really say the same thing about them.
You don’t get that with most tools. Ironically I think the fact that .net core has moved to a more CLI sort of environment has made visual studio a worse option for it than visual studio code, but we aren’t really going down that road, so what do I care.
I do care about python support for visual studio code, and it’s damned awesome.
Visual studio does a lot of things for you without a CLI. Want to deploy? Right click on your project and do the UI wizard for it. I mean, even nuget has a gui.
On top of that C# comes with a ton of easy to use features from its library. Like AD integration is just a library that gives you everything you need, at least until it doesn’t and you have to write your own bits and things get hard, but until then everything is easy and it’s much easier than using an open source library for it. I think any C# programmer could use its basic functionality from VS without ever looking at its documentation, and while Django and flask integrates with AD as well, you can’t really say the same thing about them.
You don’t get that with most tools. Ironically I think the fact that .net core has moved to a more CLI sort of environment has made visual studio a worse option for it than visual studio code, but we aren’t really going down that road, so what do I care.
I do care about python support for visual studio code, and it’s damned awesome.
I think you are correct here, but also consider what a typical Java and C# programmer's are developing, they are writing line-of-business application's they are not data-mining, or doing a lot with algorithm's.
As you implied they are also less typically less exposed to doing the low level thing, however no one will test you if you can use the EntityFramework in the IDE while everyone will test if you can use SqlConnection, Open , Execute a query and parse the result "by hand"
As you implied they are also less typically less exposed to doing the low level thing, however no one will test you if you can use the EntityFramework in the IDE while everyone will test if you can use SqlConnection, Open , Execute a query and parse the result "by hand"
I think that would explain why they aren’t performing on par with python developers. I also think a lot of python developers started with C, and that typically makes you a better programmer, because if you’ve suffered through memory allocation and finding the paths of least resistance, you’ll never forget.
I don’t see why JAVA or C# should perform worse than JavaScript developers in terms of data structures or algorithms though. Documentation, CLI and environment, sure, but building things?
You could say something similar about go, but I think people who are choosing go, are choosing go. And by that I mean they are thinking about their options, most C# developers that I have known, simply throw C# at everything, even when they shouldn’t.
I don’t see why JAVA or C# should perform worse than JavaScript developers in terms of data structures or algorithms though. Documentation, CLI and environment, sure, but building things?
You could say something similar about go, but I think people who are choosing go, are choosing go. And by that I mean they are thinking about their options, most C# developers that I have known, simply throw C# at everything, even when they shouldn’t.
I use C# and Visual Studio a lot and I think it really makes me dumber. In my C/C++ days I used to be really good at reading docs and quickly setting up configurations but now I am used to the IDE doing a lot of handholding. I am some work with node now and I notice that in this environment you have to know the command line and read a lot because things are less polished.
It's because the process is CS heavy. Slinging business logic together while mapping it through some ORM to satisfy the latest priority shift this sprint is what the average C# and Java engineer excels at. It's more craftsmanship and less computer science.
C# is very well thought out language. It development team is super experienced in language design. Its head designer Anders Hejlsberg has made other languages. And they borrow stuff from other languages like lambda etc.
I think he means he has no idea why candidates of those languages are less likely to meet his pass criteria
If I recall correctly the test is 100% automated. Write code, run tests. Answer multiple choice. Humans and their bias need not apply.
There is always bias in something manmade. The tests might be slightly unfavorable for certain kind of developers.
In some comment here it was mentioned that the C#-tests are not good enough and some others mentioned that this company seem to favor dynamic languages. Maybe there is some truth to that.
In some comment here it was mentioned that the C#-tests are not good enough and some others mentioned that this company seem to favor dynamic languages. Maybe there is some truth to that.
> Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews?
I think it comes down to users of those editors probably are used to keeping code/libraries in their head more. IDEs tend to suggest a lot to you and if you're not used to having that happen you could get more nervous during whiteboarding rituals.
Edit: I guess this really doesn't apply as their interview process is on the web.
I think it comes down to users of those editors probably are used to keeping code/libraries in their head more. IDEs tend to suggest a lot to you and if you're not used to having that happen you could get more nervous during whiteboarding rituals.
Edit: I guess this really doesn't apply as their interview process is on the web.
I have tried VSCode a few times for C++ on macOS and always found it more hassle than it was worth to get it up and running.
I saw it had debugging options and I thought that looked pretty cool but it is a bit of a mess with tasks.json and some other file I have forgotten about now. I recall I did finally get a working setup but it wasn't portable between folders/projects as the binary filenames were hardcoded and I just lost interest in fixing it.
I think the VSCode team could make this a lot smoother. I want my tools to simplify these things for me with automatic configuration like every other editor seems to be able to do. Not sure why VSCode needed a couple of json config files to know to use /usr/bin/gcc on the current C++ file when no other programmers editor does.
I saw it had debugging options and I thought that looked pretty cool but it is a bit of a mess with tasks.json and some other file I have forgotten about now. I recall I did finally get a working setup but it wasn't portable between folders/projects as the binary filenames were hardcoded and I just lost interest in fixing it.
I think the VSCode team could make this a lot smoother. I want my tools to simplify these things for me with automatic configuration like every other editor seems to be able to do. Not sure why VSCode needed a couple of json config files to know to use /usr/bin/gcc on the current C++ file when no other programmers editor does.
I'm not sure when the last time you've tried, but in the last year VSCode has come a long way towards "just working" out of the box for C++. They've specifically focused on it. If you've got some time, I'd recommend that you checkout Rong Lu's CppCon 2018 talk. https://www.youtube.com/watch?v=JME1i3vCRR8
> With 17% of the pie, VS Code was the editor used by the majority of Triplebyte candidates last year.
Huh? This has broken the world of math for me.
Huh? This has broken the world of math for me.
They mean plurality.
It's interesting to me that Go does so well. I have a buddy who convinced his shop to switch over to Go for the following reason: he knew that they were not going to be able to consistently hire good programmers, and he thought Go was a way to mitigate the problems arising from this situation. In other words, Go is a language where newbie programmers can still do okay. He also claimed that Google developed Go for this reason, referencing the infamous Ron Pike quote ("They're not capable of understanding a brilliant language, but we want to use them to build good software").
Go makes it really hard to do stupid things, and that makes it a really good language.
This article has some very interesting data beyond just showing the rise of VSCode. Fun read.
Just as an aside, there is this sentence in the article: "On the peninsula, where larger companies tend to be located, you see a lot of Java developers. In San Francisco, where startups dominate, you see more JavaScript."
None of the non-SF cities is on the peninsula. They're 100% in the Silicon Valley / Santa Clara Valley.
None of the non-SF cities is on the peninsula. They're 100% in the Silicon Valley / Santa Clara Valley.
I was also surprised to see how much VS Code has grown in popularity among WakaTime users in such a short amount of time. [1]
https://wakatime.com/static/img/wakatime-editor-usage-2018-1...
https://wakatime.com/static/img/wakatime-editor-usage-2018-1...
Intellij, pystorm, Android Studio (and half of "Other") make up more than a quarter and are the same jetbrains editor with different plugins pre-installed and some plugins unavailable..
That is more than VSCode and these identical IDEs are all over the place in these charts.
So what was I supposed to have learned from this article?
That is more than VSCode and these identical IDEs are all over the place in these charts.
So what was I supposed to have learned from this article?
Worked with a bunch of them, always come back to Sublime Text for performance and multi-cursor support.
Can't really speak to performance comparisons, but VS Code has has multi-cursor support for a while now.
Emacs has multi-cursor support. http://emacsrocks.com/e13.html
Is that native?
It isn't, and it's better because of that.
All "advanced" features should be a plugin so you can pick your favorites. This way, if someone comes up with a better multi-cursor system, there's no politics involved about which multi-cursor system to come to a global consensus on. Just switch your personal config over to the new plugin and get on with your life.
All "advanced" features should be a plugin so you can pick your favorites. This way, if someone comes up with a better multi-cursor system, there's no politics involved about which multi-cursor system to come to a global consensus on. Just switch your personal config over to the new plugin and get on with your life.
Hum. The things is it's probably breaking other features and other plugins then. Try Sublime one once. It's like night and day. Everything works as if you were in single cursor mode.
I used sublime for about a month and couldn't get used to it. Maybe I'm just too indoctrinated into Emacs. :)
No, but why would that be a concern? If you're going to use Emacs as your environment, it's best to learn how to install additional packages, as you'll get a lot more functionality that way. If you're using Sublime or VSCode, I'm sure you'll one day install plugins for it as well.
At least for me, sometimes I have to work on servers where I don't have sudo privileges, so I usually can't install plugins.
You don't need sudo privileges to install packages for Emacs. They reside in the user's directory.
Are sublime multi-cursors different from code multi-cursors?
What I would gladly pay 100$/month for is Vim with correct syntax highlighting, intellisense and nice plugins (such as fuzzy finder) by default.
It would not need to be Vim, but I have only tried one Vim emulator that didn't suck and was terminal-first: emacs with evil-mode. Let that be the bar for vim-emulation.
Why is nobody doing this? I think this would appeal to a lot of people.
The criteria for me to to pay for something like this would be:
1. Terminal first. It would either have to become my main shell or open fast within my shell.
2. Vim based or with GOOD Vim emulation. Macros, remapping and all normal mode key combinations must be implemented.
3. Fast terminal<->editor loop. I don't want to wait >300ms to edit a file.
4. Actual production quality zero-config syntax highlighting, intellisense and fuzzyfinder.
Sign me up!
It would not need to be Vim, but I have only tried one Vim emulator that didn't suck and was terminal-first: emacs with evil-mode. Let that be the bar for vim-emulation.
Why is nobody doing this? I think this would appeal to a lot of people.
The criteria for me to to pay for something like this would be:
1. Terminal first. It would either have to become my main shell or open fast within my shell.
2. Vim based or with GOOD Vim emulation. Macros, remapping and all normal mode key combinations must be implemented.
3. Fast terminal<->editor loop. I don't want to wait >300ms to edit a file.
4. Actual production quality zero-config syntax highlighting, intellisense and fuzzyfinder.
Sign me up!
Funny how people analyse data and draw conclusions without applying any statistical method. Yeah, maybe more people use VS Code, but I don't think it has anything to do with people's failure or success.
> I don't think it has anything to do with people's failure or success.
Unless the interviewer is a big fan of VSC and they favour other VSC users.
Unless the interviewer is a big fan of VSC and they favour other VSC users.
VS Code has taken me off Emacs for Python development on Windows. I was never able to get a clean and speedy code completion, navigation, or refactoring to work with Emacs. I hope the situation changes someday.
The same engine that VSCode uses is open source [1]. With lsp-mode [2] or eglot [3], you can have the same stuff working inside emacs. I've actually been writing Java inside emacs lately --- yes, java, and I have had very few issues.
One caveat, development on the emacs LSP stuff is moving very quickly, so I don't recommend using ELPA/MELPA/etc. to install the plugins. I use straight.el [4] to manage my plugins, they're checked out from the upstream source and can be updated at-will. You'll also need an up to date version of emacs, ie: 26+. (That's the current release, but it's not available in some distributions ie: debian/ubuntu yet.)
---
[1]: https://github.com/Microsoft/python-language-server
[2]: https://github.com/emacs-lsp/lsp-mode
[3]: https://github.com/joaotavora/eglot
[4]: https://github.com/raxod502/straight.el
One caveat, development on the emacs LSP stuff is moving very quickly, so I don't recommend using ELPA/MELPA/etc. to install the plugins. I use straight.el [4] to manage my plugins, they're checked out from the upstream source and can be updated at-will. You'll also need an up to date version of emacs, ie: 26+. (That's the current release, but it's not available in some distributions ie: debian/ubuntu yet.)
---
[1]: https://github.com/Microsoft/python-language-server
[2]: https://github.com/emacs-lsp/lsp-mode
[3]: https://github.com/joaotavora/eglot
[4]: https://github.com/raxod502/straight.el
Python-lsp with emacs is dreadful bad. It's slow, bugged and doesn't integrate well. Worst is how often the helper dies.
The microsoft-helper is supposed to work better, but it seams harder to setup with linux, so I hadn't the chance yet to try it.
The microsoft-helper is supposed to work better, but it seams harder to setup with linux, so I hadn't the chance yet to try it.
It's hard to beat pycharm especially on Windows...
The killer feature for my switch from Atom was the built in terminal. Enough to let me be ok using a ms product temporarily to try it out. I appreciate their energy behind it - the update schedule, the changelog write ups, the listening to the feedback from the users.
I really liked the json config of atom. the code gui isn't my fave but it's ok.
Two other things helped me transition easily:
- click a button to edit `PATH` or whatever so that `$ code` opens up the editor from the terminal
- atom keymapping
The coffee script use in atom was unfamiliar territory for me too, so that part seemed distant.
I really liked the json config of atom. the code gui isn't my fave but it's ok.
Two other things helped me transition easily:
- click a button to edit `PATH` or whatever so that `$ code` opens up the editor from the terminal
- atom keymapping
The coffee script use in atom was unfamiliar territory for me too, so that part seemed distant.
> The first thing that jumps out from this graph is the prominence of Visual Studio Code.
Maybe to some. 10.2% percent for vim!
For some reason that makes me really happy even though I use emacs. I guess the (d)evil you know...
Maybe to some. 10.2% percent for vim!
For some reason that makes me really happy even though I use emacs. I guess the (d)evil you know...
Anyone who still uses VSCode, probably haven't read about all the features IntelliJ and its ilk offer.
The local history, for example, and its integration with the test runner (knowing at which point of your editing process your tests started to break) has saved me a tremendous amount of time.
(I've accidentally erased changes that were uncommitted with a stroke of a `checkout -f`, and managed to save hours of work with that feature alone.)
These conclusions are frustrating to read because they haven't handled the numbers properly at all and have drawn poor conclusions.
Take a scenario where Java/C# are popular and have 20 people applying for each position but Go isn't and only has 5 people applying for each position.
You'd then have a far far better "pass rate" for Go developers. But it doesn't actually say anything about Java or Go in terms of developer proficiency.
Take a scenario where Java/C# are popular and have 20 people applying for each position but Go isn't and only has 5 people applying for each position.
You'd then have a far far better "pass rate" for Go developers. But it doesn't actually say anything about Java or Go in terms of developer proficiency.
[deleted]
The only issue I have with VS code is it's awful UI/UX performance - it behaves like an Electron app or something.
I realize that's a fair insult around these crowds, but it really does have that lack-of-polish, weird-UI/UX feeling. I know Microsoft would obviously never build an IDE off it, but I'm almost curious to see what on earth they did wrong.
Comparing it side-by-side with Xcode is certainly the easiest way to tell.
I realize that's a fair insult around these crowds, but it really does have that lack-of-polish, weird-UI/UX feeling. I know Microsoft would obviously never build an IDE off it, but I'm almost curious to see what on earth they did wrong.
Comparing it side-by-side with Xcode is certainly the easiest way to tell.
Because of the popularity of VS Code on HN, I decided to give it a try. It's good. Much better than Electron or Atom for my workflow. And much faster IME.
The one thing that keeps me from switching from my current IDE is the lack of Whitesmiths brace formatting. I'd pay up to $15 for a Whitesmiths plugin. Until then, I can't change. But I'll keep checking.
The one thing that keeps me from switching from my current IDE is the lack of Whitesmiths brace formatting. I'd pay up to $15 for a Whitesmiths plugin. Until then, I can't change. But I'll keep checking.
For those not familiar (as I was), here's what Whitesmiths style looks like (straight from Wikipedia):
while (x == y)
{
something();
somethingelse();
}
finalthing();The horror!
Yep the loop never runs, is infinite, or x and y are member or global variables that are mutated elsewhere.
In which codebases is Whitesmiths formatting used? It looks so wrong if you're used to any of the other styles.
It's popular with ancient Windows C/C++ projects, so of course developers who use this have never seen other styles.
VS Code uses Electron.
Thanks for clarifying that. I must be thinking off another editor that used Electron as its base, and only the Electron portion stuck with me.
I went through and deleted all of my unused editors a few months ago, so I wasn't able to go back and make a complete/accurate list of the ones I've tried in the past.
I went through and deleted all of my unused editors a few months ago, so I wasn't able to go back and make a complete/accurate list of the ones I've tried in the past.
Nuclide, maybe? There are a bunch of Electron-hosted text editors and for awhile it seemed like atomic-theory-based naming conventions were going to take over.
Nuclide is just a giant “Let’s reinvent everything” add on from FB add on Atom. Frankly, it has a bunch of very weird and hard to configure functionality that’s already provided (or can be provided) as separate plugins for Atom. It’s really awkward and painful, reaks of FB.
All that said, the remote code editing has the best editing UX, but at the same time, super sucks because it requires a special nodejs server to run on your remote system, and that requires yet another watchman daemon, and all this needs to stay version compatible with your Nuclide plugin.
I don’t recommend it, unless you currently work at Facebook. Otherwise, just use Atom.
All that said, the remote code editing has the best editing UX, but at the same time, super sucks because it requires a special nodejs server to run on your remote system, and that requires yet another watchman daemon, and all this needs to stay version compatible with your Nuclide plugin.
I don’t recommend it, unless you currently work at Facebook. Otherwise, just use Atom.
Hey, I'm familiar with VS Code language extensions. Depending on your language you may or may not be able to do this. The controls you have are:
- increaseIndentPattern: If a line matches this pattern, then all the lines after it should be indented once (until another rule matches).
- decreaseIndentPattern: If a line matches this pattern, then all the lines after it should be unindented once (until another rule matches).
- indentNextLinePattern: If a line matches this pattern, then only the next line after it should be indented once.
- unIndentedLinePattern: If a line matches this pattern, then its indentation should not be changed and it should not be evaluated against the other rules.
They are all regex patterns. If you think your language would let you do that, I can try and throw together something for you.
- increaseIndentPattern: If a line matches this pattern, then all the lines after it should be indented once (until another rule matches).
- decreaseIndentPattern: If a line matches this pattern, then all the lines after it should be unindented once (until another rule matches).
- indentNextLinePattern: If a line matches this pattern, then only the next line after it should be indented once.
- unIndentedLinePattern: If a line matches this pattern, then its indentation should not be changed and it should not be evaluated against the other rules.
They are all regex patterns. If you think your language would let you do that, I can try and throw together something for you.
From a point of anthropological curiosity, do you work in a team where everyone uses that style of brace indentation?
Is it actually common and I've just never encountered it before?
Is it actually common and I've just never encountered it before?
I don't think it's common, but one of the projects I work on has the entire codebase and documentation already in Whitesmiths.
I don't know much about the history of how it came to be that way, but it's my understanding that pretty much everyone else who's ever worked on the project came either from big iron, or had big iron in their background. Maybe that's where it came from.
I could just be used to it now, but I find it much easier to follow what's happening in the code than Ratliff or K&R.
Horstmann and Lisp aren't bad, either. They make a lot more sense than some of the other options that litter the screen with braces in seemingly random places.
I don't know much about the history of how it came to be that way, but it's my understanding that pretty much everyone else who's ever worked on the project came either from big iron, or had big iron in their background. Maybe that's where it came from.
I could just be used to it now, but I find it much easier to follow what's happening in the code than Ratliff or K&R.
Horstmann and Lisp aren't bad, either. They make a lot more sense than some of the other options that litter the screen with braces in seemingly random places.
I've never worked in a Whitesmiths codebase, but I always thought it looked nice.
The one downside compared to what I mostly end up working in is that it wastes some vertical space because the opening brace is on a new line.
The one downside compared to what I mostly end up working in is that it wastes some vertical space because the opening brace is on a new line.
What is big iron?
In my experience, it generally refers to mainframes or other specialized and powerful servers.
It means mainframes.
[deleted]
What language do you write?
I like VSCode a lot. The only reason why I sometimes switch to other alternative is the multi-file search results. When the fix this, I will be a happy camper: https://github.com/Microsoft/vscode/issues/63465
What editor do Go devs use??? Their numbers for Go only add up to 12%!
https://d25hn4jiqx5f7l.cloudfront.net/file_attachments/files...
Yes, that chart shows that they have relatively few people doing their interviews in Golang, so their outlier pass rate should have correspondingly large error bars (which you have to imagine because the graphs were drawn without any statistical sophistication).
vim
Sure, maybe it is the old-school nature of Vim and Emacs that makes then standout in performance, but why not throw a years-since-graduation variable into the equation to find out with greater certainty?
I recently helped make a VS Code extension during a Microsoft internship, and I found the language server interface really easy to use. It really makes it easy to write an extension.
"Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews? Perhaps they tend to be more willing to invest time and effort customizing a complex editor in the short-term in order to get returns from a more powerful tool in the long-term?"
One thing I noticed on Lobste.rs is that a lot of them like the old school editors. That's normal. What was more interesting was that they were constantly sharing and discussing their customizations that made them more productive. Kept making me want to have another go at those editors. I didn't since I came from Windows with big, full-featured editors that could do everything (or Notepad++ or Notepad). Still, I keep reading those comments since there's always new and interesting things people are coming up with.
In other words, I think the author is onto something worth further investigation and comparisons. Especially comparing VS Code programming to experienced folks using highly-customized, full-featured setups in the other stuff. I bet the results would be more interesting than a random person tried using Emacs or whatever.
One thing I noticed on Lobste.rs is that a lot of them like the old school editors. That's normal. What was more interesting was that they were constantly sharing and discussing their customizations that made them more productive. Kept making me want to have another go at those editors. I didn't since I came from Windows with big, full-featured editors that could do everything (or Notepad++ or Notepad). Still, I keep reading those comments since there's always new and interesting things people are coming up with.
In other words, I think the author is onto something worth further investigation and comparisons. Especially comparing VS Code programming to experienced folks using highly-customized, full-featured setups in the other stuff. I bet the results would be more interesting than a random person tried using Emacs or whatever.
My experience of Triplebyte's interview process is slanted towards frontend/backend developers of web apps. Fortunately for me, that was my background. However, in the team I currently work with, the team is in aggregate heavily C# with only secondary experience in web frontend/backend development. That's because their expertise is in low level security. Several developers on this team are exceptions to the "don't roll your own cryptography" adage.
They're all competent developers, but the version of Triplebyte's coding test that I took (and passed) would be in unfamiliar territory for people in this team. That's fine since most of Triplebyte's clients are probably looking for web frontend/backend skills, but I think this means that Triplebyte's test shouldn't be seen as an objective measure of programmer skill, just an objective measure of fit for Triplebyte's clients.