My assumptions here are based primarily on the fact that, as you know, on the wikipedia page of a typical linux or BSD distribution there'll be a panel on the top right corner which will tell you which language(s) it's written in, which architecture(s) it's written for, and a variety of other information, but it will not have a simple little entry telling you how many lines it consists of. Why not? I thought compressing their code as far as possible is one of if not the primary way(s) a programmer demonstrates their prowess, so why is this simple question - 'so, exactly how big is it?' so rarely asked of programs these days? Is everyone ashamed of how bloated all software is today, have they all made a pact to never ask each other that question like how you're not supposed to ask a woman her age?
It's literally a worthless metric. You can remove all newlines to make any project 1 LoC, and what will you achieve?
>>2
just follow the typewriter/fortran standard
>>3
I don't feel like it.
Because it's not of interest to anyone. As an end user, a program could have 1000, 100000, or 100000000000 lines of code, and it would make no difference whatsoever to me.
And if you think that many LOC = bloat, then I don't even know what to tell you. It sounds like you never wrote a large program before.
Binary size is more interesting, especially on mobile.
Code bumming used to make sense in the 60s, when you directly wrote in assembler, and each line was an instruction that mapped directly to what was executed by the machine. In high-level languages this is not the case, and one liner can perform several orders of magnitude worse than 20 lines long algorithm. In fact, the longer version can be made more robust with error checking and such.
And anyway, any line count bum you might have achieved with an obfuscated, mystery one liner is completely invalidated by people having to carefully consider what it does, and what the intent was. It's usually better to write things more simply, even if it ends up more verbose. That, of course, does not apply to things like well-established idioms of the language used, or of the program itself.
I wish programmers were paid by the number of lines of code added each day.
I could become a zillionaire in no time.
Laypeople would look at me with awe, and accord me with the respect that I deserve.
I would belong to the holy priest class, where I speak vague wise words in exchange for donations.
Computers are holy objects that should only be used by priests.
I would of course contribute to peasant society by using my personal computer to predict solar eclipses.
People will be amazed by the predictive powers that I yield with the help of holy computers.
Priests are the only ones who know how to tame a computer.
Peasants therefore have to pay tribute to the priests to avoid angering the computers.
The future of the priest class is very bright.
>>5
you're a terrible programmer
>>7
hahahahahahahahahahahahaha, bumming
Lines of code has very little meaning for me as a measure of "code quality". In any system, there will always be a minimum level of "complexity" that's necessary to properly encode and solve the software problem at hand. Reaching that theoretical minimum level of complexity a matter of expressing the logic in pure lambda calculus. I have no desire to read lambda calculus encoded real world problems.
My personal measure of "code quality" is all about readability that allows me to grok the intent of the logic such that I can make further updates to the logic in a safe manner. I want to the ability to grok bugs in the logic and otherwise tinker with the logic to improve the software towards the users' context.
>>10
Retard.
Shoo, roach
>>9 Fuck yeah /g/ro, we are true programmers that know C without understanding pointers and are suckless and /g/ool. We can change font in dwm one of the most difficult feats in /g/rogramming and N/g/ complete and doesn't afraid of anyone. Check out my e/g/in one liner /g/roski! $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval All our /g/reat /g/ro/g/rams are on one line to hide the fact that they never go above 1000 lines when properly formatted, cuz we r da true /g/rogrammers.
>>13
Suckless stuff is pretty good though, if dwm was ported to wayland I would probably use it.
sucktard garbage
good
Kys
>>6
Binary size is completely irrelevant because the size of code is neglegible in comparison to videos and images, even if you're using SBCL.
>>16
Show us on the doll where the suckless developer touched you.
*points to anus*
>>15
Why do you think its good? What feature do you like that makes your use it.
NIGGER
>>21 best program optimisation is the NIGGER opcode
Tsk.
>>20
It's been a while since I've used dwm, but one thing I still notice in sway is the lack of golden-ratio mode (doesn't exist in i3 either IIRC). Bigger than any individual feature though is how easy it is for programmers from outside the suckless project to implement patches like that for dwm, because the codebase is so nice and clean.
>>24
Sway is missing quite a lot and tbh the only apps I run are xterm, firefox, mupdf, and openscad. Wayland would only break things and run slower. I really don't understand why everyone is so quick to switch. The main argument seems to be that it prevents them from accessing their own data? That just sounds annoying.
Very few programmers are autistic enough to care about really optimizing code size beyond some simple edits
>>25
Screen tearing while watching videos, I still experience it in both firefox and mpv under xorg. That's the only reason I use wayland.
>>27
I don't understand why people care so much. but yeah, If screen tearing is a serious issue for you (more serious than low latency and basic features working) then you want Wayland.
I seriously doubt the average Windows user would even notice though.
>>27
`Option "TearFree" "true"`
>>29
I was shocked when I first tried enabling that. It makes Xorg as tear-free as Wayland!
>>29
WTF? The fact that this is real is almost comedic.
https://manpages.debian.org/bullseye/xserver-xorg-video-intel/intel.4.en.html#Option~11
imagine waiting possibly an entire frame for Xterm to draw a character after you type it