Thread by @gravislizard

OK so here's an opinion I'm going to issue in re: programming. hello

A tremendously popular piece of advice is "look at other peoples software to help you learn how to code" but the way modern code works, you can't do that.

Let me explain: If you wanted to figure out how, say, Doom worked, the source code is NOT HARD. There's. Like. v_game.c, and you can open it and read it and there's code that does something.

I just decided I wanted to try to figure out how the roc k et chat client did a particular thing so I went to the github and I am completely lost. I can't find any code that DOES ANYTHING

Everywhere I go I just find these tiny stubs, helper functions, nothing of SUBSTANCE. there's no "client.js" that CREATES THE CLIENT, that I could read and look at the includes and chase down code paths

Enterprise Java is similar. I spent two years trying to figure out how our CRM at work functioned and the Java code is absolutely goddamn bizarre. Nothing seems to DO anything. It all just sets up data that's used by some distant monstrous framework.

Here. I want to find the code that does embeds, like when you paste a URL and the message window includes a little preview of the page contents. Let's go to the repo.

Where do we start?
I guess "client"? Since this... this is a clientside behavior, afaik? Alright here's client.

ok so startup can't be it, notifications wouldn't be it. helpers?

guess not. next folder

okay, it's not lib.

none of this looks likely... updatemessage? nah, i looked at it, it's just the routine for editing a message, it doesn't do any display

well, i know a little bit about django and stuff so... maybe routes has all the possible destinations? nope.

these literally just build "routes". no includes. nothing to point to what *file* I need to look at.

I even peeked in startup. None of these contains more than maybe 20 lines of code.

So where's the program? I just clawed through everything that ostensibly is "the client" and there's no program. There's tiny chunks of code that, honestly, I don't even understand why they're in their own files they're so small.

External Tweet loading...
If nothing shows, it may have been deleted
by @frameslip view original on Twitter

As stated, yes, it actually is under /packages/rocketchat-oembed.

My guess is that this is because it's *flexible* and *modular*, meaning that nothing is securely connected to anything else. The base program - if you can even find it - provides a void container and a raw API hole.

Let's go look at oembed and see if we can figure it out.

alright so... client, obviously?

hmm. lot going on here.
my particular interest is in how it parses unknown URLs. so it looks like the only things i'd be into are basewidget and maybe urlwidget?

here's basewidget and this is gettin me somewhere. i have done a LOT of ajax and a LOT of reverse engineering at this job so I can infer that this is picking a widget based on content-type. unfortunately i'm not sure what picks between the last three

googled sandstor m grain and whatever it is it's some third party app so ok, mark that off. next likely is the html thing let's look at that

uhhh ok framewidget is empty. but whoops i remembered - again, *tons* of experience, like about as much as you could ask from an amateur - that maybe the html file contains something. sure enough, a template

at this point i have notions of how this works. however, if i had not
- built complicated ajax scripts
- made my own webapp with pyramid
- spent easily 80 hours reverse engineering Java EE code
i would have been stopped after like step 3

having reached this point, i STILL don't know where any of the data in those template fields comes from. there's mystery meat somewhere that's creating it all

but the way that IMPERATIVE code, e.g. index.php worked, was this:
#include <lib_read_webpage>
#include <lib_templates>
webpage = rwp.open($url)
variables = webpage.parse()
template = templates.populate("webpage.tmpl", variables)

everything was right there. in the new world, every code file, no matter what, is being dropped by some god-hand into the middle of a shitload of state and unless you understand the whole app holistically, you know nothing

all that java code would just make reference to objects that just didn't exist ANYWHERE in the project. they were created in entire other SVN branches, in different packages.

chasing it down, trying to find something that ACTUALLY triggers the method that opens an SSH connection or writes a file to disk, is basically impossible. impossible unless you are the dev attached to the project 40 hours a week.

nothing you look at is imperative, nothing is isolated, nothing actually exists in a vacuum. it's all being slammed into an incredibly crowded scope by mechanisms you can't see

so, wrapping up: a lot of the time, asking a new developer to read other peoples code is basically a non-option because they literally will get nothing from it. The repo I linked is absolutely opaque - i can tell you plenty still are to me.

modern software, while not all like this, is largely like this. Any webapp in particular is built inside these Frameworks which basically combine your code in non-euclidean ways which only make sense if you've been doing *only that*

point i'd like to make: I'm not sure I've ever met anyone who worked on webapps (django-style with routes and shit) who also worked on anything else, ever.

actually i have figured out what upsets me and here it is: webapps, java EE code, etc. are all a nightmare of gotos

it's not quite the same. but it's the same. If you're reading code, you have /no idea/ where the execution pointer goes at any given moment. It could jump to literally another repo.

The problem with goto is that the pointer goes somewhere else, /changes the state of the machine in unknowable ways/, and maybe comes back but you have no idea where it was and what it was doing

This is the same situation. You cannot understand the program without understanding *the whole program*. piecemeal, it's gibberish. 99 out of every 100 characters of a method is somewhere else.