sillysaurus3

Exactly this. Little things, like why can't you just write `fs.readFileSync(<server URL>)`? That's all you want to do. You don't want to deal with issuing a fetch call and setting up handlers and so on. That should be abstracted from you. Ad everyone has their own ways of doing this, and you just search for whatever JS lib happens to tickle you that day. It's the opposite of a unified engine model.

Why does that matter? Because the easier your code is to write, the faster you can write. And the larger the systems you can create, individually. Since system value scales inversely proportional to the number of people working on it, that means you alone can build something in a few days that would normally take a team of programmers quite a lot longer.

Think of it this way. Why bother writing React? There were existing solutions. Yet we all saw what happens when you ignore standard ways of doing things and push for something better.

Two specific examples: You want to write blocking code, no callbacks and no awaits, and you want greenthreads. The reason you want this is because your codebase becomes exponentially smaller. And the only way to accomplish this in JS is to essentially write your own programming language on top of JS. Not really a transpiler, but more like an entire scheduler with heap allocated memory and page tables.

If that sounds crazy, just imagine how crazy it would've sounded to try to mix HTML inside of javascript before JSX.

The central theme here is simplicity and generality. HN's codebase proves what a single dev can achieve when you focus exclusively on these two goals.

EDIT: Some design inspiration: https://www.youtube.com/watch?v=Ox2H3kUQByo&t=1340s

This is one of the few games where Lisp is used, and they show how and why it enables them to do easily what other games struggle to.

She mentioned the other day that she's a bit sad she can't find any aspect of React she doesn't know. But now she's been banging her head against react native for the past few months, so there's no shortage of challenges. She's the primary architect of a startup's frontend webapp (and now their mobile app). I keep trying to push her to write and post her stuff, but she still feels like she doesn't know anything. But that feeling seems like the main reason she knows so much now, several years later.

React devs probably have a moment when react suddenly makes sense.

In all four cases (bicycling, music, pointers, react) what makes the difference is dogged persistence. One day you'll wake up and things will seem simple -- and the next challenge impossible. Rise and repeat.

You'll have to implement each part yourself to understand them. It's not something that can be skimmed. But it's so worth it.

After that, most of the mystery of graphics will be gone. (But not the thrill.)

One of the most frustrating aspects of learning graphics programming was that most resources immediately start talking about theory. Partial derivatives of uv's and xy's, gradient values and mipmap selection, and you're just trying to draw a damn picture on a triangle. Learning from working code and implementing it yourself is a better teacher.

Consider a website whose img src references are not actually strings, but instead are pointers to memory addresses. Your application works like this: When you attempt to dereference the pointer, a page fault fires, which causes the underlying system to load the image from the server. When the loading is complete, your program resumes.

Big deal. But this opens up another interesting avenue: It's very easy to return a different image while you're waiting for the original to load. Meaning there is no async/await -- no waiting at all. You just write code in the natural, blocking way. No callback hell or promise chains.

There are other interesting applications of this too. When you dereference the pointer to the image, you know the user's viewport size. Meaning you know how large the image should be. Therefore the underlying system can automatically request a perfectly-sized image from the server -- or have the server construct it on the fly, then stream it to the client.

You never have to deal with any of this complexity yourself.

The most important area where this type of design is applicable is gaming. You want to stream the exact texture miplevels you need, at an ~infinite level of detail. If you approach a wall, you want to see lots of high resolution wall textures. But when you move away from the wall, that texture data should be freed. The above architecture handles this type of concern automatically.

Failure was accepted as a part of the culture. Today it seems the opposite. Any hint of failure and people seem to distance themselves from your future ambitions.

More and more, we seem to be moving toward a world ruled by massive corporations, where small developers have almost no autonomy or freedom, and we're subservient to the concept of intellectual property and non-disclosure. The age of tinkerers building something huge seems to have been a short-lived historical accident.

That's related, because the only way to build something huge is to repeatedly fail at it. And that doesn't seem acceptable today.

We are moving in August, keeping just one of the venture funds here in San Francisco. The judgement call that I am making is that in the next decade it will be less centralized where technology happens and that the incredible premium on this location will not be quite as big anymore.

I'm shocked that everyone here is focused on his politics when he's making one of the biggest moves SV has seen.

Sama seems to partially agree: http://blog.samaltman.com/e-pur-si-muove

To me these are ideologies that go beyond just disagreement about how best to structure a society, how powerful government should be, or what its priorities should be. I think the thing they have in common is that they explicitly advocate hurting people and more importantly believe that you can actually make the world a better place by hurting certain people. You can make the world a better place by inflicting pain.

I think the defeat of Germany in WW2 has proved that's true.

So back to Thiel and his politics. Nowhere in his writing have I ever heard him explicitly advocate any of those things, but the company he keeps is another story. He seems to hang around with a fair number of explicit doctrinaire fascists.

explicit advocacy of genocide

Since this article's off the front page, it probably won't hurt to delve into politics for a bit here. So I have to ask: What specifically are you talking about?

Yes, you do. That's pentesting 101.

Think of it this way. Would it be reasonable for pentesters to say "You're critically vulnerable. But I haven't verified this"?

More times than I can count, when I went back to verify whether I was correct, I wasn't. For subtle reasons. If you haven't put in the work, you don't know whether you are right.

Security, most of the time is about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?

You have never worked in security. The fact that you're shocked at this shows how green you are. I don't mean that in a dismissive or insulting way, but if you'd just go do a stint as a pentester for a year, or talk to some pentesters in the field, you'll quickly stop being shocked at this.

You have a responsibility as someone who is presenting security issues to know what you're talking about. Most people listen to whoever talks the most confidently. And the bare minimum work is proving that the exploits you're presenting are actually applicable to the situation at hand.

Most people don't know security, and very few people will check your work to ensure it's correct. That means when some hobbyist steps up and starts yelling about theoretical issues, it's important to step in and say "Actually, these issues haven't been demonstrated."

What if it takes $100M to MITM someone? Would you say it's still worth being shocked that you're theoretically vulnerable to this? What is the precise cost of someone who actually wanted to MITM someone else using emacs? Have you done the math?

This isn't me downplaying the significance. This is me saying "Do the work." And if you haven't, then you should classify the vulns as low severity. That's what we did whenever we didn't know for a fact that you could own someone's app/box.

The reason I laid out some creds is because you seemed to ignore the substantive part of my comment, twice now.

It is tradition in the security field to make every security incident seem like a very big deal. (See tptacek's comment on cloudflare's memory leak, for example.) But just because there exist vulnerabilities, it does not mean that (a) anyone has exploited them or (b) that you are in any kind of danger.

I was shocked that I've been exposed to a dozen TLS vulns that might cause arbitrary code execution the whole time since package.el became a part of Emacs back in circa-2013.

This sentence makes it sound like anyone who has used emacs in any way since 2013 has been in immediate risk of having their computer taken over. Maybe that's true. But even if it were true, what precisely would the steps be to make this attack happen? Have you proved that it can be done?

EDIT: The main point I'd like to get across is that it's worth fixing security problems, but it's important to maintain a spirit of cooperation rather than accusation. Everyone has security issues. Even (perhaps especially) the big names that you wouldn't expect to. That's why people pay pentesters a lot of money -- we're effective at making sure no one else finds them before we do. But emacs doesn't have the resources to get a pentest, and out of all the security vulnerabilities they could possibly have, a few TLS flaws wouldn't even be marked as medium severity unless there were a direct way to take over a user's computer via the flaw.

To bring this back to the topic at hand: npm as an ecosystem is far more vulnerable than the points you mention. It's worth considering why people do not routinely pwn those who use npm. The fact that you are vulnerable does not mean it's a good idea to try to throw an entire ecosystem under the bus.

Beyond that, npm is far more vulnerable. But it rarely matters. The reason is culture and community.

But it's mistaken to say HN is a free marketplace of ideas.

I could give some substantive points in support of this statement, but it's an old conversation and I've gotten in trouble for the ways I've expressed it in the past.

If I want it faster than that, or cheaper, I walk to the home depot a mile away.

I recently got rid of my car after four years of living in a city. I don't know why I held onto it for so long, but my life has improved dramatically. Not only can I go anywhere I want, but I never have to worry about permits, tickets, or parking.

This lifestyle can't work for people outside of cities, though. There's no way to get anyplace without a car, and there isn't enough density to make uber very effective. No one wants to wait a half hour for a ride.

Being in a city has downsides, but for this reason it's wonderful. There's even an app now where you can just use someone else's car. (Getaround, I think?) I've used it twice: one when I needed to go buy something about 20 miles away, and another to go on a trip a hundred miles away. And the price was very low.

It might be a bit hard to swallow, though. Who's to say that a streamer is less qualified to analyze character writing in MMOs? After all, the writer is usually not the one impacted by the game. Streamers are.

I know nothing about this situation, though. </hedge> I'm just saying that it would personally feel difficult to adopt this mindset if I felt like I were qualified to express a dissenting opinion.

Thank you. This was a legendary answer. I really have been hunting this question for years: https://news.ycombinator.com/item?id=13764917

This seems like how he did it. Error correcting codes are a natural domain for questions like "What are the fewest gates gates required to transmit some information?" But the missing puzzle piece was that you can analyze them with polynomials.

http://longnow.org/essays/richard-feynman-connection-machine...

By the end of that summer of 1983, Richard had completed his analysis of the behavior of the router, and much to our surprise and amusement, he presented his answer in the form of a set of partial differential equations. To a physicist this may seem natural, but to a computer designer, treating a set of boolean circuits as a continuous, differentiable system is a bit strange. Feynman's router equations were in terms of variables representing continuous quantities such as "the average number of 1 bits in a message address." I was much more accustomed to seeing analysis in terms of inductive proof and case analysis than taking the derivative of "the number of 1's" with respect to time. Our discrete analysis said we needed seven buffers per chip; Feynman's equations suggested that we only needed five. We decided to play it safe and ignore Feynman.

How do you analyze boolean circuits using partial differential equations?

What else can you accomplish with this technique?

No one seems to know how he did it.

Dragging an old $10 USB keyboard around with you makes you look like you really like mechanical keyboards.

It's been about a year and a half now. I guess you get used to it.

pg's and rtm's original arc3.1 is on the "official" branch: https://github.com/arclanguage/anarki/tree/official

news.arc is the old HN source code. You can run it by following the steps in how-to-run-news.

(Run it with "mzscheme -f as.scm" though, not mzscheme.)

Some feature requests were a matter of days, like user profiles: https://news.ycombinator.com/item?id=481

A brief essay on some HN design decisions: https://pastebin.com/bSW5dfRQ (from https://news.ycombinator.com/item?id=8424502)

I think the arc codebase is worth studying and understanding, primarily so that you can extend its simplicity into your own projects. The reason HN was such a success is because it handles so many cases in the same way: Stories, comments, and polls are all the same thing: items. If you want to add a new thing, you just create a new item and add whatever fields you want.

These rapid prototyping techniques have downsides, but the cure is to keep in mind what you can't do. (For example, you can't rename item keys without breaking existing items, so be sure to choose good names.)

Like emacs, HN's design is borne out of simplicity and generality. It's what you get when you write the next most important feature as quickly as possible, then cut as much code as possible, every day. Both halves are equally important.

It's fine to say that our modern applications are so much more complicated that the old lessons don't apply. And in extreme cases, that may be true. I don't think SpaceX has the luxury of rapid prototyping their software.

But the typical app is CRUD. For those, data processing flexibility is perhaps the most important factor in whether you can write new features quickly. And since code is data, a lisp master can write systems with a shocking number of features in shockingly few lines of code. (See Jak'n'dexter: https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...)

  FreeBSD 10.1
  Nginx 1.7.10
  Racket 6.1.1 with some HN and FreeBSD specific patches.

  2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore)
  8x16GB Kingston 16GB DDR3 2Rx4
  SuperMicro X9DRI-LN4F+_R1.2A
  Adaptec 71605
  9x 1000GB Western Digital WD RE4
  2x 200GB Smart XceedIOPS SSD

Most of the work is server side, e.g. voting ring detection. We only notice indirectly, when the quality of the site goes up.

"The key to performance is elegance, not battalions of special cases."

  eval === this[[1,18,-3,8].map(x=>String.fromCharCode(x+100)).join("")]