I feel like require-from-twitter really helps enforce the Unix philosophy. It's hard to write modules with multiple responsibilities in 140 characters.
Actually, there are several immutable FS-over-tinyURL projects. I have created some of them too. A real problem with Twitter is that you can get banned quickly for doing this.
Twitter allows deletions and explicitly requires you to process and honor deletion events in their TOS. They have even blocked API access to programs that don't honor deletions.
So, just as bad (or, maybe worse, in that you can't even keep around committed code that comes through this process, if the originating tweet was deleted) as npm.
Twitter API clients are required to delete all copies of tweet contents when a tweet is yanked, or Twitter will revoke API access, which might bring your production systems to a deserved halt.
You have left out a very crucial fact which completely destroys your argument: Twitter has no verification process that the tweet was deleted because you're NOT ADVERTISING THE TWEETS. You're using them as source code. So the public is NOT privy to what you're doing with the tweets! So Twitter would have to get a search warrant to determine that you aren't deleting tweets! Of course they don't care; they care about what you're revealing to the public.
Your computer has to download the tweet before it runs the tweet. It will be cached on your computer. Compliance with twitter TOS means you have to clear your cache when twitter says the tweet was deleted. Since you're using the tweet to run code, it doesn't hurt anything if you ignore the "deleted tweet" advisory.
The problem right here. Just to run a script you now need to import a whole third party language runtime ? what other language does pull this kind of stunt ? Javascript is madness.
Most of that is so people can use the slightly nicer syntax of the newer version of JavaScript in a more supported way as it's transpired. Honestly I'm not a fan because, as you can see, it's a big ass bucket of extra complexity for some extra, albeit nice, syntax updates.
I'm waiting for wide support of ECMAScript 6 before I start using it widely. Though I feel I'm a bit in the minority here I just don't want to deal with all of the transpiling complexities if I don't need to.
I've started using ES6 sans 'transpiler' for web development on Chrome. There's still the build step for release to other browsers, but so far I haven't bothered.
(I think your decision is completely reasonable; only pointing out that since just this month, with Chrome 49 out, you can develop without any build step.)
Yup. I'm working on a Polymer project in ES6. I develop in Chrome with it pointing directly at my source, so I get a full debugger and quick reloads by hitting the F5 button. Then I use crisper/babel/vulcanise via a ninja build script to generate an ES5 deployment package for the other browsers. It works really well.
(ES6 is so, so much nicer than ES5. It's almost like a real language now!)
Yes, but you'd need to expand the source file rules inline --- I added the Lua because I was fed up with doing it by hand. (Ninja doesn't have implicit rules.)
Note that other browsers (specifically Firefox and Edge) generally have better ES6 support than Chrome does, so a "build step" is not needed for them unless you happen to be using one of the very few things that Chrome supports and they do not.
Indeed, it is the only post-build babel dependency required if you want things like you say: async/await. The rest are the babel dependencies are build tools.
Javascript is in fact special because it's one of the few languages where the developer can't choose the version of the language to use. It's dictated by users with 4 year old browsers.
For scripting languages, sure. For compiled languages, you can choose whatever version you want, since the end user gets a binary blob instead of source code (and even if they're building from source, their package manager should be able to download the required build dependencies for them).
Where? Java has such short maintainable cycles that Java 7 was dropped before Java 8 became used, and compiled languages (think C, C++, Haskell) always work.
Are there any other languages relevant for non-server usage?
That's nearly never the case, unless you are running uncompiled scripts downloaded from the internet with no version manifest, in which case that's also horrible.
I don't think it's the amount of code that is a problem here (we all depend on million lines of codes for a simple hello world program in C). The problem is the number of sources that one should trust to run it, which should be minimal.
First of all, whoosh, and second, no other language has the same platform/delivery mechanism as web client javascript. Any "transpiled" language is going to have to include it's own dependencies somehow.
Well this is meant to be a bad example, really all the babel stuff would be dev dependencies and ideally you'd have some watch task to compile and auto-reload.
In production you'd only have a bundled/minified version transpiled JS so there's no need for a runtime.
Ultimately with web assembly this gets even better.
Tangentially related(tweet sized js) and an awesome project: https://t.d3fc.io/ is a collection of d3 visualizations from tweets. The code is cryptic on first inspection, but if you look at the sandbox setup, it starts to make sense and 140 chars is a wonderful constraint. eg: https://t.d3fc.io/status/694991319052103680
A developer gets upset at unilateral actions by NPM resulting in a project being renamed or taken down unnecessarily (potentially breaking builds). So this dev decides to take down all their projects, as a sort of protest. This breaks a lot of builds. The JavaScript community thinks a clever solution is utilizing Twitter as part of the build process? Because then everything would be dependent on Twitter not adding an "edit tweet" button...
Neither can npm module versions without direct assistance from the company (which, if you were able to gain favor, you might be able to get Twitter to do the same).
The only difference is someone can't take over a tweet should the original tweet author delete their account.
For everyone who doesn't know it, there's a project called http://140byt.es/ compiling many code snippets that fit in a tweet (;
There was also a clever trick to compress/uncompress ascii text by using base[huge number] or something like that (full unicode) so it could be uploaded to twitter, but I don't remember the exact number
this would actually be an interesting coding challenge and experiment to see if something could be built worthwhile in modules limited to no larger than 140 characters.
If a repo meets certain criteria in licensing, create the ability to "Static Publish" a release. This feature communicates that the version repo is the public's and cannot be removed by the individual or team. Github also enters the agreement that if there is ever a need to "move" the version due to copyright infringement, it provides either aliasing or sooner sort of notification and time bomb before it goes offline.
If this were done, folks could be in the know about which packages and dependencies are at risk, so they enter into the install with their eyes wide open.
> require-from-twitter is the core code for the tweet package manager. Our beta version has only one dependency: npm. But we're working hard on adding more dependencies as quick as possible.
One of the interesting side-effects here is that while it encourages you to write very small packages, it also strictly caps the maximum number of packages which you can add as dependencies of your own package. There's only so many `require` calls you can fit in a Tweet.
I know this is supposed to be funny, BUT if you vendored and kept a local copy in you're build environment, you wouldn't have to worry if the tweet gets deleted.
This is the lesson I see noone talking about.
Of course, using a tweet as a source for a library is silly.
This person wrote a tweet and the tweet has code[1]. This snippet in JavaScript allows you to import that code into your code as a module. I think this is trolling on state of the Node community because over the previous few days, people have found some pretty interesting dependency architecture[2].
If you can get a good toolkit for writing a GLR parser, then people will write their own tokenizers, BNF formal grammars, and plug it into your parser. It would take a single person about two to six weeks to get something thoroughly polished in JavaScript along the lines of what is described. However I think that without some form of centralization, (perhaps a subreddit? idk) it will be difficult for the standardization and namespace organization process to take place. If it is just one person, there is no question of standardization; if it is multiple people, the question of who is in charge of the namespace becomes relevant. Who is in charge of the namespace in this particular experiment?
This is also probably a snarky shot at npm [1], for those who lack context.
[1] https://news.ycombinator.com/item?id=11340510