Pullup, the site you join via pull request(pullup.io) |
Pullup, the site you join via pull request(pullup.io) |
"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.
The satellite that you join via pull request can be written in whatever you want :)
"Pull me up, Scotty!"
"Almost everybody who works on a website knows JavaScript."
That I can agree with.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?
> 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.
(FWIW, I do know JS)
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.
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.
Assumption confirmed!
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.
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.
Honest question and not trolling. Can I send a pull request to update this text to "We figured JavaScript is very popular these days....."
EDIT: I just did it anyway. Feel free to accept/reject
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.
Still, interesting project.
On the bright-side at least the project is MIT. Good ol' MIT.
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 :)
The old saying, "don't fix it if it ain't broke."
HAHAHAHA, good luck with that.
(But still, a nice idea for a site)
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.
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.
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.
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.
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.
But then I guess the downside would be fewer people contributing to your own site.