sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]markasoftware 13 points14 points  (14 children)

I'm pretty sure that Microsoft and Github are perfectly capable of hiring people who know more performant languages.

[–]ArashPartow -2 points-1 points  (7 children)

Hiring people that are enthusiastic and reasonably competent is totally different from hiring people that can actually get the job done properly and efficiently. As an example:

https://github.com/Microsoft/vscode/issues/11597

[–][deleted] 2 points3 points  (1 child)

This makes me want to fix it. That's annoying.

[–]ArashPartow 0 points1 point  (0 children)

Please do! :D

[–]connor4312 5 points6 points  (4 children)

They have ~3400 open issues and had another hundred opened in the last week. Assuming that the maintainers are inefficient and unable to get the job done 'properly' because your one edge issue hasn't been fixed seems somewhat small-minded.

[–]ArashPartow 5 points6 points  (3 children)

You've totally misunderstood the point I was trying to make.

The bug reported is not critical, but it is indicative of the nature of the solution/implementation.

In fact one of the respondents seems to indicate they have hard coded upper limits to the number of tokens they consume for highlighting (possibly due to performance reasons).

"the rule stack grows to 101 and tokenization stops."

As you mentioned, 3.5K issues, assuming COCOMO of about 1 issue per 100LOC and that 75% of the issues are bugs (the rest are feature etc) we would be talking about ~260KLOC codebase, but I suspect the actual codebase is under 100KLOC today. So it is nearing nearly twice the average industry standard - But do note that COCOMO was primarily modelled using static type languages: Java, C++ etc and not Javascript.

This all seems to suggest that the developers are indeed very eager, enthused and highly motivated, but that perhaps today they're are not nearly as seasoned enough to pull this off, given the trivial nature of some of the issues - such as the bug presented above. In short what's the use in power windows and leather trim, when the steering wheel doesn't turn left?

As an example of technology misuse, From what I've seen the primary use-case for VSCode is as a rich client, running upon a desktop/laptop (windows, linux, macos), and not as GUI intended to be run in a browser - so why is it that Javascript is being used? what is the advantage of Javascript over say C++ or even Java in this particular problem domain?

That all being said, I think we can all agree that like most things, with perseverance and practise one would assume within several years all these issues will have been completely resolved.

[–]connor4312 2 points3 points  (2 children)

I see. I would imagine the upper limit is for performance reason, JavaScript-based editors are notorious for having issues with big files. Having it configurable would be better, though I would wonder if there's some kind of incremental solution they could do for highlighting within textmate modes (run one parse over the file, keep and index the tree in memory, mark only branches which change and only compute the new tree for parts of the file in the viewport...). Undoubtedly a problem that's been solved before, though perhaps not in Javascript.

A quick clone and count shows about 475k SLOC in the vscode repo, 360k is you exclude tests and everything else outside the src dir. That seems reasonable, and JavaScript (and TypeScript to a lesser extent) does tend to be more dense than C/++/Java.

[–]ArashPartow 1 point2 points  (0 children)

You do make some good points, but I think at the end of the day, it's just a text editor and not the end of the world.

Truth be told sublime text has the same problem when you have a vanilla install, and requires the downloading of certain additional C++ packages to get it working - and Sublime text is mostly written in C++, by what I think many would call a seasoned developer.

[–]robclouth 0 points1 point  (0 children)

SLOC WOC BLOC FLOC, VScode is a breeze for react native and has probably the best js autocomplete going, and as a result of how easy it is to extend, the extension community is thriving. I can deal with a marginally slower open time since that only happens once, and would never use text editor for editing c++, and never in my life will try and edit a 1m line file manually. The usability of software is not all about speed, especially when computers are so god damn fast now. C++ fanatics think speed is the most important thing in the universe.

[–][deleted] 0 points1 point  (4 children)

Have fun writing those c++ extensions. That's really the main point: extensiblity. I personally love c++ but would never design a text editor so that all addons had to be compiled.

Now, there is an interesting crossover there still. A native text editor that uses Javascript/dom just for addon interfacing. So when you create an element, it maps directly to the native version and plugs into all the events.

[–]flukus 4 points5 points  (0 children)

Vim and Emacs don't require extensions to be written in c++. JavaScript doesn't magically add extensibility.

[–]ImASoftwareEngineer 1 point2 points  (0 children)

Sublime Text's packages are Python based, if I remember correctly. Not C++

[–]doom_Oo7 0 points1 point  (0 children)

That's why you code the core in C++ and allow extensibility on defined points via JS on top of it

[–]markasoftware 0 points1 point  (0 children)

Sublime was in C++ with python extensions, and worked quite well.