5 ms·

Trivial apps depending on 14+ million lines of code is not a good thing. Edit: @michaelmior I think you know what I mean.

michaelmior 10y ago
I think a good terminal emulator is far from trivial. Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.
- Jtsummers 10y ago
  https://www.openhub.net/p/putty https://www.openhub.net/p/putty Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code. EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.
  - destructionator 10y ago
    I wrote a terminal emulator <https://github.com/adamdruppe/terminal-emulator> https://github.com/adamdruppe/terminal-emulator> and use it daily so it is good enough for me at least... clocks in at ~15k lines (including the gui helper lib). The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.
  - deleted 10y ago
    [deleted]
- alaroldai 10y ago
  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.
- e12e 10y ago
  git clone git://git.suckless.org/st cloc --quiet st http://cloc.sourceforge.net v 1.60 T=0.09s (45.8 files/s, 56588.2 lines/s) ------------------------------------ Language files blank comment code ------------------------------------ C 1 497 253 3654 C/C++ Header 2 40 124 313 make 1 13 2 45 ------------------------------------ SUM: 4 550 379 4012 ------------------------------------ [ed: Actually, this get even more extreme for the terminal I actually use everyday, sakura[1]: apt-get source sakura (cloc sakura) Gives a total of 2490 lines of code, of which 2380 are C, the rest is CMake, make and Bourne Shell... that is cheating of course, as sakura uses libvte: which clocks in at ~45K lines of C - and a total of ~103K loc all together. Still a far cry from millions of lines of code... [1] https://bugs.launchpad.net/sakura https://bugs.launchpad.net/sakura ]
  - michaelmior 10y ago
    Sure. I wasn't arguing that millions of lines of code are necessary for a terminal. Thanks for the pointer to Sakura though! I quite like it and I might have to give it a try :)
jahewson 10y ago
How many lines is the JDK? or .NET, or libcpp?
- teamhappy 10y ago
  LLVM: 1.5 million (I assume libc++ is less than 500k) OpenJDK: 6.8 million .NET: 10.5 million Source: https://www.openhub.net/ https://www.openhub.net/
sgrove 10y ago
I agree, but I'd take it a step further - the 15+ million Lo(memory-unsafe!)C for the unix kernel other (all?) trivial apps sits on is also not a good thing.
- teamhappy 10y ago
  I agree with your larger point (I think) but for what it's worth: Most of those 15+ million lines are drivers you don't use.

michaelmior 10y ago

I think a good terminal emulator is far from trivial. Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.

Jtsummers 10y ago
https://www.openhub.net/p/putty https://www.openhub.net/p/putty Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code. EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.
- destructionator 10y ago
  I wrote a terminal emulator <https://github.com/adamdruppe/terminal-emulator> https://github.com/adamdruppe/terminal-emulator> and use it daily so it is good enough for me at least... clocks in at ~15k lines (including the gui helper lib). The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.
- deleted 10y ago
  [deleted]
alaroldai 10y ago
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.
e12e 10y ago
git clone git://git.suckless.org/st cloc --quiet st http://cloc.sourceforge.net v 1.60 T=0.09s (45.8 files/s, 56588.2 lines/s) ------------------------------------ Language files blank comment code ------------------------------------ C 1 497 253 3654 C/C++ Header 2 40 124 313 make 1 13 2 45 ------------------------------------ SUM: 4 550 379 4012 ------------------------------------ [ed: Actually, this get even more extreme for the terminal I actually use everyday, sakura[1]: apt-get source sakura (cloc sakura) Gives a total of 2490 lines of code, of which 2380 are C, the rest is CMake, make and Bourne Shell... that is cheating of course, as sakura uses libvte: which clocks in at ~45K lines of C - and a total of ~103K loc all together. Still a far cry from millions of lines of code... [1] https://bugs.launchpad.net/sakura https://bugs.launchpad.net/sakura ]
- michaelmior 10y ago
  Sure. I wasn't arguing that millions of lines of code are necessary for a terminal. Thanks for the pointer to Sakura though! I quite like it and I might have to give it a try :)

jahewson 10y ago

How many lines is the JDK? or .NET, or libcpp?

teamhappy 10y ago
LLVM: 1.5 million (I assume libc++ is less than 500k) OpenJDK: 6.8 million .NET: 10.5 million Source: https://www.openhub.net/ https://www.openhub.net/

sgrove 10y ago

I agree, but I'd take it a step further - the 15+ million Lo(memory-unsafe!)C for the unix kernel other (all?) trivial apps sits on is also not a good thing.

teamhappy 10y ago
I agree with your larger point (I think) but for what it's worth: Most of those 15+ million lines are drivers you don't use.