5 ms·

Visual Studio Code: https://github.com/microsoft/vscode https://github.com/microsoft/vscode

sharpercoder 9y ago
I second this. Not only is the code well-written, the whole codebase is architected in a modular and layered way. Many things are well documented. You can probably step up your game and write a plugin for VSCode as an exercise. The VSCode codebase is evidence TypeScript is built to scale further then Javascript.
- frik 9y ago
  Its editor component "Monaco" is the single reason that TypeScript exists. TypeScript was created in conjunction with (or for) this first project, of course the editor was first used in other parts of MS, and only later was also integrated into VSC.
kevindqc 9y ago
Opening the VS Code inside VS code? I would feel watched, like my VS Code is wondering what the hell I'm doing. Is it not good enough for me? Is it failing me in some awful way that I feel compelled to change it? Maybe it should get out of the IDE business if its not good enough? Maybe become a farmer, take a break from technology
- jrowley 9y ago
  Or you can think about it as looking under the hood of a car, or taking apart an iPhone to appreciate the beauty. But I do love the irony. I imagine people have run binary decompilers on the decompilers themselves before.
  - fermuch 9y ago
    I remember the tale someone fuzzing the same fuzzer to find bugs. I can't find the link though. General tools like an editor, a decompiler, or even an image editor can be used to modify the software itself. After all, if you're the creator of the tool itself, most likely you feel comfortable using it. What I always wonder is how people built the first tools. How did people compile the first version of GCC? How did people build the first programming language? How did people built the first OS? I can imagine ways to solve these, but I guess the tale behind how they did it is what makes me wonder.
    - chadgeidel 9y ago
      The general term is "Bootstrapping" https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers) Generally you start with "something smaller/easier" and build your way up.
noir_lord 9y ago
I learnt a lot from looking at the code code base when it was first released (and back when TS didn't have so much material available).
jczhang 9y ago
How does one approach looking at a (large) codebase with intent to learn? Where do you begin?
- igorgue 9y ago
  Read "Working Effectively with Legacy Code"
legohead 9y ago
if (!!process.send Is there something I'm missing here? Why not just: if (process.send
- nicolashahn 9y ago
  `!!x` is guaranteed to evaluate to a boolean value of `true` or `false`. `if (x)` evaluates truthiness of `x` which in Javascript land might behave differently. I don't know how off the top of my head, but I know it's something to be cautious of in this language and its derivatives.
  - Stratoscope 9y ago
    An if statement works exactly the same whether you pass it a boolean true or false, or any truthy or falsy expression. In other words, these are 100% equivalent: if( anything ) { ... } if( !!( anything ) ) { ... } The !! is redundant here, unless there's something relevant that isn't shown in the if statement excerpt in legohead's comment.
    - always_good 9y ago
      It's just explicit coercion. If there was a linter rule I could turn on to require booleans in if-conditions, I'd enable it. `!!` might seem silly, but it's a hint that you intended for coercion to happen. A similar but better example would be preferring `if (x > 0)` over `if (x)` even though non-zero is truthy. There's an even better case for returning `!!x` from a function even though you could return `x` and let the call-site coerce it. The problem with that is that the call-site can build a dependency on the value of `x` beyond truthy vs falsey. In a weakly typed language like Javascript, I don't think you'll ever regret being a little more explicit.
      - kybernetikos 9y ago
        I much prefer the more explicit `Boolean(anything)` for this reason.
      - 9y ago

I second this. Not only is the code well-written, the whole codebase is architected in a modular and layered way. Many things are well documented. You can probably step up your game and write a plugin for VSCode as an exercise. The VSCode codebase is evidence TypeScript is built to scale further then Javascript.

frik 9y ago
Its editor component "Monaco" is the single reason that TypeScript exists. TypeScript was created in conjunction with (or for) this first project, of course the editor was first used in other parts of MS, and only later was also integrated into VSC.

kevindqc 9y ago

Opening the VS Code inside VS code? I would feel watched, like my VS Code is wondering what the hell I'm doing. Is it not good enough for me? Is it failing me in some awful way that I feel compelled to change it? Maybe it should get out of the IDE business if its not good enough? Maybe become a farmer, take a break from technology

jrowley 9y ago
Or you can think about it as looking under the hood of a car, or taking apart an iPhone to appreciate the beauty. But I do love the irony. I imagine people have run binary decompilers on the decompilers themselves before.
- fermuch 9y ago
  I remember the tale someone fuzzing the same fuzzer to find bugs. I can't find the link though. General tools like an editor, a decompiler, or even an image editor can be used to modify the software itself. After all, if you're the creator of the tool itself, most likely you feel comfortable using it. What I always wonder is how people built the first tools. How did people compile the first version of GCC? How did people build the first programming language? How did people built the first OS? I can imagine ways to solve these, but I guess the tale behind how they did it is what makes me wonder.
  - chadgeidel 9y ago
    The general term is "Bootstrapping" https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers) Generally you start with "something smaller/easier" and build your way up.

noir_lord 9y ago

I learnt a lot from looking at the code code base when it was first released (and back when TS didn't have so much material available).

jczhang 9y ago

How does one approach looking at a (large) codebase with intent to learn? Where do you begin?

igorgue 9y ago
Read "Working Effectively with Legacy Code"

legohead 9y ago

if (!!process.send Is there something I'm missing here? Why not just: if (process.send

nicolashahn 9y ago
`!!x` is guaranteed to evaluate to a boolean value of `true` or `false`. `if (x)` evaluates truthiness of `x` which in Javascript land might behave differently. I don't know how off the top of my head, but I know it's something to be cautious of in this language and its derivatives.
- Stratoscope 9y ago
  An if statement works exactly the same whether you pass it a boolean true or false, or any truthy or falsy expression. In other words, these are 100% equivalent: if( anything ) { ... } if( !!( anything ) ) { ... } The !! is redundant here, unless there's something relevant that isn't shown in the if statement excerpt in legohead's comment.
  - always_good 9y ago
    It's just explicit coercion. If there was a linter rule I could turn on to require booleans in if-conditions, I'd enable it. `!!` might seem silly, but it's a hint that you intended for coercion to happen. A similar but better example would be preferring `if (x > 0)` over `if (x)` even though non-zero is truthy. There's an even better case for returning `!!x` from a function even though you could return `x` and let the call-site coerce it. The problem with that is that the call-site can build a dependency on the value of `x` beyond truthy vs falsey. In a weakly typed language like Javascript, I don't think you'll ever regret being a little more explicit.
    - kybernetikos 9y ago
      I much prefer the more explicit `Boolean(anything)` for this reason.
    - 9y ago