

A command-line power tool for Twitter - adpreese
https://github.com/sferik/t

======
chippy
I think the king of command line clients is TTYtter - I love it.

[http://www.floodgap.com/software/ttytter/](http://www.floodgap.com/software/ttytter/)

~~~
sedev
To my great sadness, TTYtter is currently unmaintained (I sent in a bug report
and that's what the dude told me). So I expect it to stop working at some
point. Until then, best desktop Twitter client for me by a mile.

I wish Twitter, Inc weren't the _absolutely stinking worst_ maker of Twitter
clients. :(

------
spindritf
This has many cool features and is easy to use in scripts but if you just want
Twitter in your terminal, check out Twirssi[1]. It plugs into irssi which many
have running already anyway.

[1] [http://twirssi.com/](http://twirssi.com/)

~~~
Foxboron
Using bitlbee for this is awesome aswell. Then you don't need to run several
scripts for more functionality (g+, Facebook, jabber etc)

~~~
sc68cal
The problem with Bitlbee is that it does not support twitter lists. I had a
project to add that support, but my C is very rusty :(

------
justizin
yes, please! have needed a tool to help deal with unfollowing some folks for a
while, i am always at follow limit, and when you're in the ui follow list it
starts with the people who tweet the most and who you interact with the most
afaict, so i end up scrolling for ages trying to find anyone uninteresting.
people seem to show up multiple times in infinite scroll, too, so it's like
digging a fucking hole in sand.

------
mantrax5
"Multi-threaded: Whenever possible, Twitter API requests are made in parallel,
resulting in faster performance for bulk operations."

That's not what threads are about.

~~~
aeroevan
Why not? Thread pools are great for doing bulk operations... long API requests
is a great thing to do in parallel when possible.

~~~
ajanuary
There's a runtime overhead of spinning up a bunch of threads that are just
going to sit idle waiting for an API response. There are better asynchronous
models for that sort of thing.

~~~
gcr
Even if starting a new thread takes 1ms, that pales in comparison to the 300ms
network connection.

On my laptop, thread creation (pthread_create() followed by pthread_detach()
takes ~17 microseconds.

When one end of a socket is on the Internet somewhere, connection time is
~80ms. If I start a thread and then have it create a network connection,
eliminating the therad spawn overhead couldn't save more than 0.02% (that's
two percent _of a percent_ ) of the running time, by Amdahl's law.

The effect of thread creation just isn't significant here. If this utility is
going to spawn 1,000 simultaneous API connections to twitter, the threads
could all be started by the time the first connection succeeds.

(My numbers come from a class assignment where I benchmarked some unrelated
stuff, but if you're interested, I can send you the report)

