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.
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.
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.
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
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.
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.
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.
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).
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.
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?
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.
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...
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 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].
132 comments
[ 9.8 ms ] story [ 204 ms ] threadThis is also probably a snarky shot at npm [1], for those who lack context.
[1] https://news.ycombinator.com/item?id=11340510
[1] ES6 features (arg defaults, destructuring, modules, template literals, String.prototype.repeat), babel configuration and runtime compilation, async / await
It's a funny PDF, though.
Amazing.
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.
Reclaiming a module name requires a breaking version for any new code, so it shouldn't be an issue there.
Writing a monitor for all of Github would even be possible.
Search warrants are incident to criminal activity in the United States of America. Twitter is a private company, not a law enforcement agency.
The only difference is someone can't take over a tweet should the original tweet author delete their account.
Yep, just like NPM modules.
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 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.)
(ES6 is so, so much nicer than ES5. It's almost like a real language now!)
https://github.com/davidgiven/gruntle/blob/gruntle/build.nin...
https://github.com/davidgiven/gruntle/blob/gruntle/build
build is a tiny Lua preprocessor which expands templates in build.ninja.
It needs a cleanup but it works, it's way faster than gulp, and is much easier to debug. Haven't touched grunt so I don't know how it compares there.
Are there any other languages relevant for non-server usage?
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.
The JavaScript community thinks a hilarious, tongue-in-cheek solution is utilizing Twitter as part of the build process.
FTFY
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
> I wanted people to be able to share HATETRIS replays via Twitter.
> Twitter supports tweets of up to 140 characters. "Tweet length is measured by the number of codepoints in the NFC normalized version of the text."
[1] https://github.com/ferno/base65536#why
On the plus side: if you saw this dependency in a module you were looking at you would know to think twice.
On the plus side: if you saw this dependency in a module you were looking at you would know to think twice.
[1] - https://twitter.com/rauchg/status/712799807073419264
[2] - http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/?...
and he even had space for a comment in there....