> stigma coming from the academic side that dataset collection is a low-level problem not worthy of serious algorithmic investment
Agreed it needs more attention, but - for academia - I think it's more of an incentive issue than a stigma issue. E.g. harder to benchmark the performance of two algorithms if they don't operate on the same dataset. Also to be fair, research into things like synthetic data mitigates the problem, just in a different way.
The paper you cited is interesting. Thanks for sharing. Hopefully that spawns more focus into understanding the subtleties of each dataset. IIRC Kaggle also had issues around generalizability, but for different reasons.
Anyways it's still early on... but we're currently building tools to help solve this problem. In particular simplifying the data collection / labeling process for vision systems. Would love to chat further w/ anyone interested in providing feedback. Email is [email protected]
It's indeed "an incentive issue" only not the one you've mentioned, but the one OP hinted at. Research is focused on what's publishable, hence tenure-trackable, and not on what's useful to solve real-world problems (of course, the two occasionally coincide)
Why so black and white? There are many incentives at play, and many ways to contribute to solving real world problems.
I’ve spent time in both academic research and industry.
Research is not supposed to be immediately applicable. The goal is to produce new knowledge - more importantly shared knowledge. Publishing is not a bad measure of that. Additionally, ability to secure grants provides incentive to focus on problems others want solved.
No incentive system is perfect, but I don’t really see how this is any different from any organization. And I don’t think it’s fair to judge an entire discipline by the negative examples.
Good question. From an engineering perspective, the codebases are different, so (with the exception of some components like JS/TS language service) the two will continue to evolve separately until we invest further in consolidating engineering efforts. From a product perspective, VS and VSCode appeal to different communities, and we need to be cognizant of that whenever we consider lighting up new functionality. Is there a specific feature or improvement you're especially excited about?
Nothing specifically, sorry. :)
I'm getting back into the MS stack after a multiple year absence. VSCode works really nice and I expect the same from the latest VS version (which I have not used professionally yet). Dunno, just excited about diving back into the whole ecosystem.
The Node Tools extension is meant for developing apps built on Node, but VS has always had top notch support for C++ so there should be no reason why you can't use them together.
Check out this tutorial for developing a node addon in VS, and let me know if you have any ideas on how to improve the experience.
Code and VS are different products, codebases, Etc. But if you see a specific feature you'd love to have in code or v.v., let us know, as we're always considering ways to collaborate wherever it makes sense.
I believe ams6110 meant that there is no need for Mozilla to build their own search engine from the ground up when they could simply partner with DuckDuckGo.
I can't speak for other teams, but re: NTVS... we definitely dont want to force abstractions upon you. For instance, with the npm integration, we provide UI where it makes sense (exploring/managing your packages, searching for packages), but you can drop into the cmd line or .npm command in the interactive window anytime you please. Think of it as semantic zoom - allowing you the flexibility to traverse the levels of abstraction when it makes sense. Are we 100% there yet? No. But I consider that to be the ideal experience, and we're definitely trending closer to that vision.
Thoughts? I'm especially curious to hear how you think we can improve the existing experience so that it caters better to your workflow. What are some of the abstractions that get in your way?
Fwiw we have remote debugging to any OS, so you can remote debug your app regardless of whether or not it's running on azure. We are striving to streamline this experience as much as possible, so any feedback or ideas you have on how to mitigate some of windows issues you've run into would be super helpful. :-)
The two major issues I have run into with doing node on Windows are likely out of your control. First is the file path length limitation, which conflicts with the nesting of npm dependencies. Second is dealing with any packages that depend on node-gyp for compilation. It shouldn't require an entire IDE to be installed in production just to build your dependencies that need node-gyp compilation. Not to mention that the process is problematic even in dev if you're not lucky enough to have installed the exact expected dependencies. I found it easier (and more portable) to just use a VM running some *nix flavor (Ubuntu for me) and deploy to a similar environment.
Agreed it needs more attention, but - for academia - I think it's more of an incentive issue than a stigma issue. E.g. harder to benchmark the performance of two algorithms if they don't operate on the same dataset. Also to be fair, research into things like synthetic data mitigates the problem, just in a different way.
The paper you cited is interesting. Thanks for sharing. Hopefully that spawns more focus into understanding the subtleties of each dataset. IIRC Kaggle also had issues around generalizability, but for different reasons.
Anyways it's still early on... but we're currently building tools to help solve this problem. In particular simplifying the data collection / labeling process for vision systems. Would love to chat further w/ anyone interested in providing feedback. Email is [email protected]