devishard

I don't think that the imprecision of human song interpretation can be used as evidence that AIs are inaccurate.

There are two levels to power that I've identified in anti-authoritarian groups. The first is the making and enforcement of the rules, and the second is the meta-game in which people get into positions of making our enforcing rules.

It sounds like your community has figured out the first kind of power somewhat, but I urge you to consider carefully the second form of power.

It's likely that your community, like many, is currently run by its founders, people who are successful leaders because they enforce rules that people want to follow anyway--people have voted them into power with their feet (if they didn't like you as a leader, they would leave).

But what happens to the community when you leave or die? Often a member of the community steps up to take the reins, and while that person might understand the goals of the organization, they might not understand how to implement those goals, especially when implementing those goals requires setting aside their own basic human urges and ego. Almost no organization survives the first few changes of leadership in a positive form. You may think you're okay with this, that your organization can end with you, but keep in mind that it may live on and cause more damage than it ever did good.

The solution is to create rules which limit your own power and give the community the ability to enforce those rules on you. That way your community has the power to survive a transition of power.

I agree, but only because questions so often go bad in titles that I now avoid them on principle. This is a rare situation where the question asked in the title is answered in a non-obvious way, so I can't actually point to anything wrong with titling this with a question.

If you came to that conclusion within a few seconds at the beginning of this article, your diagnostic criteria is basically "uses drugs -> has drug problem". A stopped clock is right twice a day, but is never useful.

Yes. Your experience might be different, but I have a limited capacity for the number of people I can remember basic facts about to be polite, so when I was keeping track of 100+ people on Facebook I didn't have the mental space to keep track of people who I met in my day-to-day.

I didn't have a plan for replacing the social contact of Facebook when I quit. I lost contact with a lot of people. But it turned out that most were acquaintances, not friends, and I could do without them. My acquaintances now are the people I see every day, the doormen and baristas I meet but don't become close with, and I find this means my acquaintances include more variety of people as a result. And the real friends, I've kept in contact with; there are only maybe 10, so it's not hard to text them occasionally.

Surely you realize production cost and value to the customer are related?

"almost every program" != "any program"

I'm interpreting "embarrassingly parallel" to mean that it's obvious the task can be parallelized, and I'm saying that many tasks where this isn't obvious in a more serial language are obvious in Erlang.

No, I'm not claiming Erlang breaks Amdahl's Law. I'm claiming that Amdahl's Law applies less often than people think it does.

I'm not saying Amdahl's Law is wrong, I'm saying that it doesn't apply to as many problems as people think it does. I said "almost" for a reason.

>> Your Erlang program should just run N times faster on an N core processor

> But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever.

You've made two claims, one irrelevant and one false:

1. only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized.

2. it's trivial to write a program that's faster in X language I'm not sure how toot define trivial, but I've yet to find a language that can communicate between threads as performant-ly. Even languages like Clojure which use similar thread semantics can't do what Erlang can because the underlying threads aren't as lightweight. Spinning up a million threads in Erlang isn't even unusual, whereas in any of the languages you mention it's either crippling-ly slow (Python or Java) or very difficult to synchronize (C most, but Python and Java aren't easy).

It's not "removing a possible value from your map", it's having your type system explicitly check that you're handling the edge case at compile time. This works in practice in a wide variety of languages.

Instead of responding to the fact that JavaScript:

1. Has no adequate threading model.

2. Has no reasonable type system.

3. Has better alternatives on the server side.

...you're making it personal, and about the people. Look at your post; you're just accusing the critics of Node of feeling "intellectually superior". That's just an ad hominem attack. And you think that critics want you to rage quit the internet and give up? No, that's not what critics of Node want. Or at least, that's not what I want.

What I want is for people to either acknowledge the problems with Node and fix them (unlikely), or start using better alternatives on the server side, and start investing more in WebAssembly and langauges targeting WebAssembly, so we don't have to use JavaScript any more. I want this because as long as Node/JavaScript are around, I have to either deal with those horrible tools, or not take those jobs.

This isn't about feeling superior, it's about improving my life by using tools that aren't godawful.

> Look at all this horrible code! So sad that all these people are not as smart as me. Look at this horrible language! So sad the people that created it are not as intelligent as me!

It's not about being smarter; smart people are a dime a dozen. It's about the fact that what happens in the industry happens to all of us. When a large chunk of the industry adopts callbacks as their threading model, that means I have to either work with their horrible threading models, or not take those jobs.

Don't psychoanalyze people who you disagree with; that's just an ad hominem attack.

> Really? There is no more "problem" with Node.js than there is a "problem" with any other platform. There is no more problem with JavaScript/ES-(name your flavor) than there is with any programming language. Different languages are different. Different platforms are different. Of course every system has its own problems. Sometimes people who appreciate them call these "tradeoffs" or the superior types call them idiotic.

This is the favored defense of people whose favored languages/tools are under attack. But this is absolutely not a tradeoff. A tradeoff is when you make a choice that has some downsides, but you get something for it.

With JavaScript in the browser, the tradeoff is clear--you use this shitty awful language and you get to run your code on the browser, because that's pretty much the only reasonable way to run your code in the browser right now. There are alternatives (TypeScript, CoffeeScript) but then you're limited to a smaller community with fewer resources.

But with JavaScript on the server, there's no tradeoff. You use this shitty awful language and you get... a shitty awful language. You don't get a reasonable threading model, you don't get a reasonable type system. You don't get anything you couldn't get from another language.

It's not a tradeoff, it's just a bad choice.

> As much of a pile of hot steaming code as it is, Babel as an idea (AKA transpiling one language to another) is pretty cool. Of course you can do this in other places but its featuring prominently in the JS community leading to an interesting result. The language and its features become configurable, easy to adapt and change and evolve over time and suit to your liking. This is interesting!

Interesting, yes, and useful. But there's really no reason this had to be written in JavaScript, and the code would likely be a lot less of a "pile of hot steaming code" if it were written in a more reasonable ecosystem.

> Of course there are lots of negatives, lots of horrible code, lots of mistakes happening.

The problem isn't that there is bad code, it's that there isn't any good code. If you needed to write a server-side program and you chose JavaScript, your code is bad and you should feel bad. It's literally impossible to write good server code in JavaScript because it doesn't provide adequate types or threading primitives. It would be different if there weren't alternatives (like in the browser), but there are alternatives which are better.

That edit is fine and says a reasonable thing that I agree with, but there are two reasons why I said "women" instead of "gender".

1. "Hackers don't give a fuck about women" is a more shocking statement than "Hackers don't give a fuck about gender" given millennial social justice sensibilities. That shock was intended, because it demonstrates to readers who aren't hackers the difference between their view and the hacker view, in a very visceral way. When you read, "Hackers don't give a fuck about gender", you have to think about it to realize how fundamental a difference in thinking that is. But when you say, "Hackers don't give a fuck about women", you can feel how different it is.

2. Gender is also a much larger issue than women in STEM. In the context of this discussion, "Hackers don't give a fuck about gender" is true, but in a larger context, I think hackers do care about gender, because gender is very hackable.