The one who kept VLC free | Hacker News Reader

The one who kept VLC free

welcometothejungle.co

98 pointswickwavy29 comments

Wow, I'm not the only one who has run into this:

> For example, when I see JavaScript developers, I ask them questions about the HTTP stack. A lot of them are just like, “Yeah, but I don’t really know about networking.” My reaction to that is, “You don’t know about networking, yet most of your time is spent on the web, over a network.”

I am saddened and how many web devs know so little about fundamentals of IP addressing, simple routing (ie: the gateway), protocols/ports, and DNS resolution/caching/TTL/etc

I'm not going to reach, but there must be parallels to this in other industries.

In the US those JavaScript developers are probably paid enough that they should know more about the giants whose shoulders they are standing on (to the extent that it would provide us with better technology) but in general yeah, abstractions are a very powerful thing.

Likewise, I hear this all the time and it's absolutely mind-blowing.

I lean more sysadmin than development, but can you imagine something like: "yeah I know bash, but I have no idea what a disk is".

What is a disk? You mean optical media, a 5.25" magnetic disk, SSD, a file system mounted over a network?

Every time this topic comes up, it smacks of "you're an idiot for not choosing to work at the same layer of abstraction that I chose [or was forced, back in the good old days] to work at".

Exactly! If you circle back around to his original objection the same argument can be made... "You use strcpy every day but you don't know exactly how it's implemented?".

That's the whole damn point of abstraction layers and his example of not knowing the details of the HTTP protocol is just as arbitrary as anything else.

I’d actually argue that it’s perhaps great that the abstractions work well enough for someone to not know networking to be productive in web development.

You can be productive, but it produces a lot of bad externalities, like news websites that load 30 trackers and drain the user's phone battery.

To be fair you don’t need to know about the TCP/IP protocol to know loading 30 trackers is a bad idea.

+1 but flip side: What _do_ you need to know?

Test your apps on a device test cloud to see how they work?

That data transfer takes time. Load less and, all else being equal, your site will be faster.

I think you should know about head-of-line blocking in HTTP1, how to fix it in HTTP/2, and maybe to test how much memory all your JavaScripting uses?

This is why computers are 100000x faster but feel no faster or slower with many "webapps"

Web apps being slow has next to nothing to do with not understanding networking.

All you need to remember is IO is 'slow'/unknown. That will get you far.

That is really sad. I just learned about HTTP about 3 months ago when I had to do my first web project so I printed out a random breakdown article on HTTP and what a beautiful design. Sure I know people think it’s far from perfect or whatever. I get that. But I loved reading that article.

As it turns out, I am learning C right now partially because I wanted to add a feature to VLC and got really curious after reading the source code and trying to assess how hard that would be.

> what a beautiful design

I’m curious: what do you find “beautiful” about http? Imho it’s just an average client/server protocol, its best quality being that it privileged readability over efficiency (using plaintext rather than then-popular binary formats).

> its best quality being that it privileged readability over efficiency (using plaintext rather than then-popular binary formats).

Not true anymore.

Hence the use of past forms for verbs.

That's why there's SREs (badass generalists): too many developers get ensconced in a tiny silo and afraid/unwilling to venture outside their turf.

Frankly, someone who hasn't:

- written a self-bootstrapping compiler

- designed and microcoded a branch-predicting, pipelined processor

- written a toy OS that works

- spent an inordinate time with assembly

- ran fuzzing against a library

can't legitimately call themselves an engineer. People who don't grasp the implications of their implementation decisions are vast the majority... and how many of them can fix things when something malfunctions at a layer that they they're unwilling/incapable of debugging? Either they can depend on some other specialists, find a local generalist engineer to fix it for them or they can "be the change they seek."

That's an incredibly high bar. I'd honestly be shocked if even the hardcore NT Kernel developers had built a microcoded branch predicting processor.

That’s a very unrealistic standard.

Almost no one has done all those things.

Most people working in the industry haven’t done most of them.

Most people with MS degrees in the field haven’t done all of them.

Writing simple compiler or OS or bootloader for learning is fine.. but "microcoded a branch-predicting, pipelined processor" is hard code stuff..

I would rather say people should at least improve algo & data structure, ability debug issues, even if they are not able to fix it...ability to find or debug thing is important.

Modern languages make everything so easy that it's hard to find anybody that knows and cares below banging Json across the wire.

This is mostly a good thing, but it makes those knowledgeable of lower levels somewhat of a rarity.

99% of Devs don't even know or care if their requests go over HTTP 1.1 or HTTP/2. Https is a total mystery unless it works okay (which is 99% of the time)

I'm okay with this. Most of these devs get their job done just fine. But I'll add that company-wide there's a small percentage of "wizards" everyone else turns to when unexpected things break. This has held true for every company I've worked for.

I'm not sad about it. Every company needs these people to function, and usually they're paid well or at least have insane job security.

>I am saddened and how many web devs know so little about fundamentals of....

And that is the reason why you see Web Devs keep reinventing wheels faster than any other Programming Domains.

And one problem I think we have today in computing is too many abstraction.

Which abstractions should we remove?

As many as possible.

From time to time you see abstractions "flattened".

For example Google with ChromeOS attempted to flatten the abstraction of having an OS containing an application (browser) containing a web-app.

The LTE standard attempted to flatten the abstraction of legacy circuit switched phone networks and just emulate the behaviours needed for existing functionality.

> copy a string by removing the backslash

I must be dumb, can someone explain this?

Reply on news.ycombinator.com