Hacker News Reader

Comment by teamhappy | Hacker News Reader

Trivial apps depending on 14+ million lines of code is not a good thing.

Edit: @michaelmior I think you know what I mean.

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.

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.

I wrote a 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.

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++).

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.

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.

> 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.

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.

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.

  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 ]

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 :)

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.

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.

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

LLVM: 1.5 million (I assume libc++ is less than 500k)

OpenJDK: 6.8 million

.NET: 10.5 million

Source: https://www.openhub.net/

Reply on news.ycombinator.com