"We figured pretty much everybody knows JavaScript"
Haha, that's funny. I guess all of the world's software runs on the web and is written in Silicon Valley. Oh wait, what's that you say, some programmers actually work on all those weird machines like satellites, assembly lines, medical devices, power plants, and even my car?! People actually write new operating systems, compilers, web servers, load balancers, and device drivers?! No way! Why don't they just make a web app for that stuff?
Yeesh. I realize that you can't please everyone, but some people chose to live in their own little worlds.
Hey there, one of the creators of the site here. When we put this line on the site we never expected it to be this controversial! It isn't meant to be a universal truth, it's just in terms of a "website you join via pull request." So, perhaps better written as: "Almost everybody who works on a website knows JavaScript."
The satellite that you join via pull request can be written in whatever you want :)
It's not about it being hard, it's about this mentality that software == web development. There is so (so) much more software running different applications. I'm not saying that the developers of this site actually think that the world literally runs on JS, but I found that sentence amusing and somewhat ignorant.
I work in systems. I don't really know JS. I do know C, C++, C#, Haskell, various dialects of Lisp, Python, and Ruby however. Why would I subject myself to learning JS unless I absolutely needed to?
My point was that JS is so much like C++/C#/Java that you do not really need to learn anything new. If you know any of those languages you can already hack JS.
> My point was that JS is so much like C++/C#/Java that you do not really need to learn anything new.
Except Javascript is a prototype based language and the others you mentioned are all object based....but hey they all terminate statements with ; so must be identical I guess.
Of course, the semicolons. Neither assembly nor python use semicolons, so by my logic they must be identical too?
Control flow, method invocations, variables, arrays, boolean logic operators, and general syntax are similar enough that you can look at the JS code and figure out what it is doing.
Ok, but that wasn't my point. I am not under the impression that it would be difficult to learn javascript. The apparent assumption that all developers already know javascript is what is telling.
As to your point, I don't remember the last time I had to think about using '==' or '===' in C++. Semantics differences are huge, I don't care about curly braces and semicolons.
Compared to web development, those communities you mentioned are very closed to most people. With Javascript, there's no special equipment needed, and you can pretty much just pick it up and go...there's tons of freely-available knowledge in blogs, and open source code to read/get involved with.
Where's the github for assembly line firmware code? I would be very interested in learning more about other non-web-development domains, but it seems like unless you get hired right out of school to program something like cars or satellites, you're pretty much shut out forever.
There are plenty of repositories with code for micro-controllers and non-web related projects, but again, that's not the point. The single quote that "pretty much everyone knows javascript" was the focus of my comment.
Sure, maybe the author meant "pretty much everyone [who we think will be interested in our site] knows javascipt", but that's not what they said, and I don't understand that attitude at all. It's unnecessarily exclusionary, especially when their plan is to host content in a similar way to HN.
Maybe another take on the idea could be to allow anyone to join who could sign in a with a github account that had had at least one accepted pull request on any repository. Easily hacked I guess, but perhaps that would solve the "just Javascript" problem while still serving to boost the average level of tech cred of submitters/commenters.
Surely there would be a way to check this through github's api once there was a username to check against. It sounds like a good idea and it might encourage supporting open source software while avoiding those issues.
But then I guess the downside would be fewer people contributing to your own site.
> We figured pretty much everybody knows JavaScript
Even with the implied "everybody" being "everybody that would be interested in joining our site", this is a poor assumption. Not everyone is a ninja-rockstar web developer. In fact, some of the best content on HN comes from people who most likely don't know JS. I get the idea for the site, but the description seems very naive.
I know javascript too, and i've been contributing, but I don't know much about Node.js apps, Express, Mongoose, MongoDB or Jade, so my contributions have been pretty meager.
I'm still not entirely convinced that it serves as an adequate social filter, however, and I agree it might be too technically limiting to lead to a diverse userbase, but as an experiment I think it's worth watching.
Famous last words. I'm not saying that JavaScript is a particularly difficult language to learn, but most people make the mistake of looking at it's syntax and then concluding that "well, it seems pretty similar to Java, I can't just start coding away instead of learning about the basics".
What language would you recommend, if you wanted to make something accessible for, say, teenagers who haven't even taken the perfunctory "Introduction to Control Structures In Blub" course yet? Javascript seems like a good guess for "language you might pick up just from everyday computer use." (Another two being, I think, Windows batch files, and Excel macros.)
I can't imagine how anyone would pick up bits of js just from everyday computer use. How many people even now the the "view source" button in their browser even exists? Excel and batch files / shell scripts I could see though.
Consider you'll probably lose lawyers like Grellas and a few others who contribute a great deal here (I think rayiner, and people in other disciplines (a few scientists here and there) who may not know programming but know their vertical better than most hackers and have a lot to contribute in that respect.
It's an interesting idea for some kind of expertise test to contribute to a public forum, but it will be very self-selecting too.
You don't need to be a ninja-rockstar web developer to know js. But more importantly, I think it would be useful to emphasize the fact that pull requests don't necessarily need to be about improvements to code.
You know, it just occurred to me: if instead of pull requests, they just accepted all pushes... that'd sort of make this the programmatic equivalent of a wiki, wouldn't it? A site anyone could edit, in a more literal sense: not just the content, but the features.
Oddly enough, you wouldn't necessarily require people to use the command-line for this, but nor would you need to build any editing UI; instead, the site could just, say, provide a context menu that contains links to the GitHub code-editor view of all the source files, and content files, that were used to render that particular element.
If you really wanted to do this, to be practical, you'd need a pretty good continuous integration server to block the deployed build from failing, but for the codebase itself, I think it'd be a fun experiment to just let people do whatever they like.
---
...or, on a different tangent, you could have something like a CI server that evaluates and accepts/rejects pull requests based on arbitrary criteria. This'd basically be a black box (not part of the editable codebase) serving the same purpose that the site administration currently does.
This process could have very specific rules, like, say, that not only does every test have to pass, but that the commit can't delete any code from a test. So features can be added to a codebase through this black box, but not removed.
Attaching such a black-box-evaluator + automatic CI deployment process to the public web would almost be like throwing a genetic algorithm at your codebase: it would "evolve" roughly according to the constraints of the algorithm, even though people are doing the work.
> not only does every test have to pass, but that the commit can't delete any code from a test.
Good idea, but this is easily gamed by e.g. adding a test that starts failing on a certain date. I've thought about this before, and it's really hard to come up with mechanisms for a system to incorporate untrusted modifications without totally collapsing.
It would be hilarious to design a program that accepts Bitcoin payments, and automatically accepts merge requests from the highest bidder.
One thing that this would be good for is almost by default members get experience working with the technologies the site is running -- they learn to use Github, deploy node.js, etc. It gives them a working technology base for their own projects.
One problem I foresee is that without a clear discussion about where the site is going, it could quickly become rife with lots of poorly-interacting features. Another is that delays in merging might well turn away valuable members.
Getting experience with the technology involved has definitely been a side effect. For example, I'm a whole bunch better at managing lots of pull requests in git versus a few days ago. It's been a really fun ride so far, no idea where it'll end up but excited to see what happens.
But never implemented / merged. Surprised the powers-that-be are resisting the most elegant solution. Then again, I came up with it, so I remain bitter and biased :)
I think the logic is that the current way isn't a big problem now that there is a standard of how you add your username to the file, and has allowed for some flexibility on the membership.
Have you read the issue? The problem is that the current way things are done requires manual merge requests because of merge conflicts resulting from the updated userlist array. The github api method is 1:1 with the requirements of joining the community and leaves no room for human error (unless the person in charge of pull requests does not standardize their own process for automatic merges).
Yeesh. I realize that you can't please everyone, but some people chose to live in their own little worlds.