5 ms·

Does it though? iTerm2 is the most feature-rich terminal I've ever used, and even then it's several orders of magnitude smaller then Electron (cloc says it's ar

Does it though? iTerm2 is the most feature-rich terminal I've ever used, and even then it's several orders of magnitude smaller then Electron (cloc says it's around 111K lines of Objective-C, with around 38K more lines split across Python and C++).

michaelmior 10y ago
Maybe it's not better. That wasn't really my point though. I'm just saying that LOC is a fairly useless metric for evaluating software. Especially from an end user perspective.
- themartorana 10y ago
  I agree with you, with regards to the end user caring or not, but there aren't many tech-unsavvy people using terminal emulators on the regular. So when Putty and iTerm2 both weigh in between 100-200k LOC and this is in the 14m LOC space, it's difficult to not make the presumption that that's a lot for a terminal emulator.
- teamhappy 10y ago
  > I'm just saying that LOC is a fairly useless metric for evaluating software. That's just not true. Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.) Rate of change is another very useful metric.
- tomc1985 10y ago
  How so? It affects load time, understandability, binary size, dependency payload... I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse. When you're moving fast and in your flow, it gets to be really annoying.
  - michaelmior 10y ago
    I was talking more about how it affects end users. Understandability of the code and dependencies are irrelevant in this case. Load time is important, but LOC is only a proxy for that metric. It's not totally unreasonable to imagine a well-written app with twice the code start faster than a poorly written one.

michaelmior 10y ago

Maybe it's not better. That wasn't really my point though. I'm just saying that LOC is a fairly useless metric for evaluating software. Especially from an end user perspective.

themartorana 10y ago
I agree with you, with regards to the end user caring or not, but there aren't many tech-unsavvy people using terminal emulators on the regular. So when Putty and iTerm2 both weigh in between 100-200k LOC and this is in the 14m LOC space, it's difficult to not make the presumption that that's a lot for a terminal emulator.
teamhappy 10y ago
> I'm just saying that LOC is a fairly useless metric for evaluating software. That's just not true. Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.) Rate of change is another very useful metric.
tomc1985 10y ago
How so? It affects load time, understandability, binary size, dependency payload... I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse. When you're moving fast and in your flow, it gets to be really annoying.
- michaelmior 10y ago
  I was talking more about how it affects end users. Understandability of the code and dependencies are irrelevant in this case. Load time is important, but LOC is only a proxy for that metric. It's not totally unreasonable to imagine a well-written app with twice the code start faster than a poorly written one.