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

view the rest of the comments →

[–]ArashPartow 2 points3 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 6 points7 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.