As a software developer, the less ambiguous your notation is, the better it is for everyone involved. Not only will I use brackets, I’ll split my expression into multiple rows and use tabs to make it as readable as humanly possible. And maybe throw a comment or 2 if there’s still some black magic involved
I genuinely hate being human for this stuff. So many things have such crazy computational shortcuts, it’s sometimes difficult to remember which part represents reality. Outside of the realm of math, where “imaginary” numbers are still a touch of enigma to me, so many algorithms are based on general assumptions about reality or the specific task, that the programmatic approach NEVER encapsulates the full scope of the problem.
As in, sometimes if you know EXACTLY how a tool works, you might still have no idea about the significance of that tool. Even in a universe where no one is lazy, and everyone wants to know “why?”, the answers are NOT forthcoming.
For real though, I have written some truly monstrous operations in Excel.
What do you mean you want to use Excel to manage everyone’s calendars? And now you want to export that horribly built calendar management spreadsheet to Google Calendar? What do you mean you want the Google Calendar entries automatically formatted based on who is working on a particular day? I mean yes it’s possible but-…
As a software developer, the less ambiguous your notation is, the better it is for everyone involved. Not only will I use brackets, I’ll split my expression into multiple rows and use tabs to make it as readable as humanly possible. And maybe throw a comment or 2 if there’s still some black magic involved
I genuinely hate being human for this stuff. So many things have such crazy computational shortcuts, it’s sometimes difficult to remember which part represents reality. Outside of the realm of math, where “imaginary” numbers are still a touch of enigma to me, so many algorithms are based on general assumptions about reality or the specific task, that the programmatic approach NEVER encapsulates the full scope of the problem.
As in, sometimes if you know EXACTLY how a tool works, you might still have no idea about the significance of that tool. Even in a universe where no one is lazy, and everyone wants to know “why?”, the answers are NOT forthcoming.
deleted by creator
Calm down, Satan
deleted by creator
The one-liner: *parses HTML with a regex*
That almost seems cute next to the shit the obfuscated c contest pulls off. https://www.ioccc.org/years.html
Further up the thread, someone mentioned that writing good software is about communicating concepts to people, first and foremost.
This, code obfuscation, is what it looks like to communicate exclusively to the compiler instead.
For some context this is one of the winning entries:
#include <stdio.h>
#define N(a) “%”#a"$hhn" #define O(a,b) “%10$”#a"d"N(b) #define U “%10$.*37$d” #define G(a) “%”#a"$s" #define H(a,b) G(a)G(b) #define T(a) a a #define s(a) T(a)T(a) #define A(a) s(a)T(a)a #define n(a) A(a)a #define D(a) n(a)A(a) #define C(a) D(a)a #define R C(C(N(12)G(12))) #define o(a,b,c) C(H(a,a))D(G(a))C(H(b,b)G(b))n(G(b))O(32,c)R #define SS O(78,55)R “\n\033[2J\n%26$s”; #define E(a,b,c,d) H(a,b)G©O(253,11)R G(11)O(255,11)R H(11,d)N(d)O(253,35)R #define S(a,b) O(254,11)H(a,b)N(68)R G(68)O(255,68)N(12)H(12,68)G(67)N(67)
char* fmt = O(10,39)N(40)N(41)N(42)N(43)N(66)N(69)N(24)O(22,65)O(5,70)O(8,44)N( 45)N(46)N (47)N(48)N( 49)N( 50)N( 51)N(52)N(53 )O( 28, 54)O(5, 55) O(2, 56)O(3,57)O( 4,58 )O(13, 73)O(4, 71 )N( 72)O (20,59 )N(60)N(61)N( 62)N (63)N (64)R R E(1,2, 3,13 )E(4, 5,6,13)E(7,8,9 ,13)E(1,4 ,7,13)E (2,5,8, 13)E( 3,6,9,13)E(1,5, 9,13)E(3 ,5,7,13 )E(14,15, 16,23) E(17,18,19,23)E( 20, 21, 22,23)E (14,17,20,23)E(15, 18,21,23)E(16,19, 22 ,23)E( 14, 18, 22,23)E(16,18,20, 23)R U O(255 ,38)R G ( 38)O( 255,36) R H(13,23)O(255, 11)R H(11,36) O(254 ,36) R G( 36 ) O( 255,36)R S(1,14 )S(2,15)S(3, 16)S(4, 17 )S (5, 18)S(6, 19)S(7,20)S(8, 21)S(9 ,22)H(13,23 )H(36, 67 )N(11)R G(11)""O(255, 25 )R s(C(G(11) ))n (G( 11) )G( 11)N(54)R C( “aa”) s(A( G(25)))T (G(25))N (69)R o (14,1,26)o( 15, 2, 27)o (16,3,28 )o( 17,4, 29)o(18 ,5,30)o(19 ,6,31)o( 20,7,32)o (21,8,33)o (22 ,9, 34)n(C(U) )N( 68)R H( 36,13)G(23) N(11)R C(D( G(11))) D(G(11))G(68)N(68)R G(68)O(49,35)R H(13,23)G(67)N(11)R C(H(11,11)G( 11))A(G(11))C(H(36,36)G(36))s(G(36))O(32,58)R C(D(G(36)))A(G(36))SS
#define arg d+6,d+8,d+10,d+12,d+14,d+16,d+18,d+20,d+22,0,d+46,d+52,d+48,d+24,d
+26,d+28,d+30,d+32,d+34,d+36,d+38,d+40,d+50,(scanf(d+126,d+4),d+(6
-2)+18*(1-d[2]%2)+d[4]*2),d,d+66,d+68,d+70, d+78,d+80,d+82,d+90,d+
92,d+94,d+97,d+54,d[2],d+2,d+71,d+77,d+83,d+89,d+95,d+72,d+73,d+74
,d+75,d+76,d+84,d+85,d+86,d+87,d+88,d+100,d+101,d+96,d+102,d+99,d+
67,d+69,d+79,d+81,d+91,d+93,d+98,d+103,d+58,d+60,d+98,d+126,d+127,
d+128,d+129
char d[538] = {1,0,10,0,10};
int main() { while(*d) printf(fmt, arg); }
I tried to read that out loud and summoned something. Please help me, I’m scared.
Pinhead: No. It is a means by which to summon us.
Excel has entered the chat
For real though, I have written some truly monstrous operations in Excel.
VBA has made things so, so much easier since I started learning how to use it.