> As others already have pointed out this metric isn't that useful in
> itself. What it does indicate is that some projects are beyond repair
> (e.g. vim).
I agree it's not useful beyond getting a ballpark estimate, esp
without taking into account external deps. The 10k figure includes
mlbuf but excludes termbox, uthash, and tests[0] arbitrarily. I
include the figure mainly to differentiate from giants like vim and
emacs. I apply the same 'small' label to vis, or any project which
packs a punch given its size.
> Having said that, I like that you took inspiration from sam (unfortunately
> it seems like either your documentation is lacking or you have left out some
> of the most useful features) and try to use/integrate external tools.
I began to question whether sam features belonged, so I didn't finish
porting. Similarly I had a vim emulation mode that I took out.
> That is already better than most editors. Keep having fun.
Appreciate the feedback. Thank you.
Adam
[0]
https://github.com/adsr/mle/blob/1e9a467/Makefile#L33-L36
On Wed, Mar 29, 2017 at 4:38 PM, Marc André Tanner <mat_AT_brain-dump.org> wrote:
> On Wed, Mar 29, 2017 at 10:54:36AM -0400, as_AT_php.net wrote:
>> > WTF. Did you write a program to generate this much? I've seen
>> > operating systems that ran really well at that line count.
>>
>> Not sure I follow your q, but yes some of it is codegen (the stdio
>> scripting part).
>>
>> My definition of sloc is roughly `cat *.c *.h | wc -l`. Using this
>> metric on other editors:
>
> As others already have pointed out this metric isn't that useful in
> itself. What it does indicate is that some projects are beyond repair
> (e.g. vim).
>
> You should at very least use something like cloc(1) which besides comments
> also filters out duplicated files. Mind you, it is still a bad metric.
> Also I felt like your numbers are a bit off/misleading, hence I took
> a quick look.
>
>> vim: 430k
>
> No comment required ...
>
>> kakoune: 27k
>
> Comparing SLOC of different programming languages makes even less sense.
> With C++ you can fit way more complexity into the same number of lines.
> The standard library includes a lot more functionality. This doesn't even
> yet take boost into consideration.
>
>> nano: 25k
>> vis: 22k
>
> This includes stuff like the vis-digraph (basically 1 large lookup table)
> and vis-menu utilities. You didn't include fzf(1) in your mle tally,
> did you?
>
> If you are fine with disabling more compile time features you could
> further subtract:
>
> 2012 vis-digraph.c
> 605 vis-menu.c
> 118 text-regex-tre.c
> 217 ui-terminal-vt100.c
> 2869 vis-lua.c
> 5821 total
>
>> mle: 10k
>
> After having a quick look, this also feels misleading. Your suggested
> shell counting glob doesn't include the core data structure of your
> editor because it was moved to an external library. A more accurate
> result would be:
>
> $ wc -l *.[ch] mlbuf/*.[ch]
> ...
> 13908 total
>
> Having said that, I like that you took inspiration from sam (unfortunately
> it seems like either your documentation is lacking or you have left out some
> of the most useful features) and try to use/integrate external tools.
> That is already better than most editors. Keep having fun.
>
> Marc
Received on Wed Mar 29 2017 - 23:25:51 CEST