Exa, a modern replacement for ls - <AUTHOR> https://the.exa.website/ <comment><USER3> Wow, the comments in this thread are quite harsh. Even though I might not use it, this looks like an awesome project - kudos to the author for finding (& implementing) ways to improve something as mundane as ls.

I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again!

Thanks for sharing this and also for your screencasts. I'd definitely spend a lazy evening watching you program exa.

<comment><USER4> _Wow, the comments in this thread are quite harsh._

I wonder if a lot of that has to do with how it's being "marketed" \--- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today (Windows' "modern UI/Metro" being one of the first examples to come to mind); not exactly the right sentiment for promoting a tool that's supposed to be long-lasting, foundational, and practical.

Perhaps if the title didn't contain "modern", the discussion here would go in a different direction.

<comment><USER5> Maybe. Whether the term "modern" was used or not, my hunch is that the response would be the same, for it is forbidden for one to deign to make these kinds of changes to fundamental Unix commands, and is tantamount to a kind of heresy (never mind that GNU implementations did this all the time wrt. original Unix implementations).

Religion... never cared for it. Re-invent the whole crappy (though still less crappy than alternatives) Unix command line, I say.

<comment><USER6> A lot of stuff depends on the basic Unix commmands though. It might be better to invent a new command name if the output differs in ways that would break both human and machine expectations. The difference between BSD and GNU versions of some commands is already enough to trip me up even after all these years. You expect `ls` to be `ls` on anything remotely POSIX/Unix-y.

I like the ideas in this tool, but it's very end-user oriented and by being written in Rust with stuff like minor Git functionality built in, definitely not as general purpose as a command like plain old `ls`.

</comment></comment></comment></comment><comment><USER7> If you're interested in learning Rust by watching someone work, the author did several long screencasts of himself working on exa: [https://www.youtube.com/channel/UCoBjY7TeCXzOULdiE40Ig1w](https://www.youtube.com/channel/UCoBjY7TeCXzOULdiE40Ig1w)

<comment><USER8> Is this a trend? Learning by seeing someone write a program? Because I find it neat.

</comment></comment><comment><USER9> It is great to scratch an itch and make something behave exactly as you want it to be - kudos.

That said, this is very much not for me. Default-colorized is something I emphatically do not want; defaulting to relative units, ditto. It it were me, the first thing I would do is get rid of 'grid' display entirely - <USER2> across just doesn't work for me. Etc.

More prosaically, `ls` is sort of like breathing for me - I do it so much during the average day that I don't even think about it. Can't say I immediately know every one of the switches, but probably 10 or so variants I use daily are pure muscle memory, and less frequently used things (extended attributes, symlink-deref options, etc.) I can remember without the man page.

So in that sense, `ls` is well into the same category as vi for me - I'm so accustomed to whatever warts there may be that switching would be much more painful than any efficiency gain.

<comment><USER10> Thanks for the kudos! It's absolutely mindboggling how many times I've decided to deviate from one of ls's default settings -- certain that the old way was inferior and outdated, and that the new way will be obvious and immensely popular -- only to find people have no idea why I'm doing things this way! I need the colours to help me scan the output; if I don't see human-readable units, I curse myself for forgetting the flag. But thousands of people don't like this, and it's usually a different set of features with each person, too. I would never have guessed I was so 'out there'!

ls is one of the most entrenched pieces of software there is; this is freeing, in a way, because it provides a stable base for people to rely on, leaving exa free to experiment. Everyone who values stability and simplicity most of all won't be switching from ls any time soon, which means I can push exa more in the direction I want it to go.

(Fun facts: very early releases of exa didn't have a grid mode at all, just the long mode, because that was the only one I used. So there have been _some_ concessions to popularity :)

<comment><USER11> I use colorized ls by default and get a bit peeved by how I have to jump through hoops to get that on OSX by default. If it works out. i'll probably alias "ls" to "exa" in the future.

That said, the binary isn't self-contained (I know, I know) so I was in the middle of compiling it from source before being pulled away for work. Looking forward to trying it.

<comment><USER10> > That said, the binary isn't self-contained (I know, I know)

It wouldn't be right if something didn't go badly wrong at the worst possible moment!

<comment><USER12> exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory

<comment><USER13> Interesting. Why does it need an HTTP parser?! Some accidental dependency maybe?

<comment><USER14> Looks like it has some form of git support, via libgit2. Dependency chain for that is probably where it came from.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I just noticed the tests and the incredible lengths the author went to in order to effectively test exa. It's _really_ impressive. GNU coreutils ls has a pretty good test suite, too ( [http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/ls](http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/ls) ), but this goes well above and beyond the call for something so new.

</comment><comment><USER16> This is heavily influenced by personal taste, but I don't understand the value of having so many elements of the output colorized. File type seems a useful case, everything else in the output of `exa -l` just looks distracting to me. Just my 2 cents.

<comment><USER17> The more design elements you add - colors, type, graphics etc - the more distracting the design get and the more conflict there is between the design elements. By colorizing everything here, nothing is important anymore. It's just poor usability and design.

<comment><USER10> (author here)

You know what's funny? Every time I have to use ls, I'm so used to seeing the colours that I have so much trouble finding anything. Which column in the permissions is group-read? I can just scan for the green one. Which file in the listing am I supposed to be looking at? I just look for the one with the yellow underline. Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".

Of course, not everyone feels this way. Colour terminals are not a new invention, and if the "colour in everything" crowd was larger, someone would have made exa sooner.

That said, I don't want to go _too_ overboard with the colours. Here's an example: when exa was in its infancy I had the bright idea to highlight the root user in red, in the same way that it highlights your current user in yellow, because, I don't know, root is "dangerous" or something. I ended up seeing so many red usernames that I stopped seeing it as "dangerous, beware" and started seeing it as "just another file" \-- which completely defeated the point! Now, red is a lot more scarce (just +w permission and inodes. probably some file types. not many)

<comment><USER18> > Colours have familiarity to me in a way that letters and words do not -- if > I expect to see green and instead see grey, I'll notice it faster than if I > expected to see "r" and instead see "-".

I think the coloration is good, but I would have defaulted a bit differently in the permissions. I would have made all user bits green, all group bits orange, and all other bits red. Not only does this denote the possible security implications of the permissions, but it also maps well to what I'm usually looking for - what are _my_ permissions, and being able to see all those quickly with green would be useful. As an added benefit, there wouldn't be as many per-character color changes in that section, so it would be less busy.

Awesome work, BTW. I love seeing interesting re-imaginings of old standby utils. I was actually thinking of doing my first real Rust project as a cat replacement. I was thinking of calling it calico. ;)

<comment><USER19> I really like a lot of the extra colors but I was also overwhelmed by the rainbow permissions. User, group, world are the organizing principle for me. World writeable is something I never want to have in my mind as similar to user writeable.

</comment></comment></comment></comment></comment><comment><USER20> I set up $LS_COLORS like 15 years sgo in my .zshrc… and haven't had to touch it since. Doesn't seem like a huge deal worth replacing it over.

<comment><USER21> It's not exactly the same though. LS_COLORS only colours file types (whether it's a file, dir or symlink) and permissions, while exa appears to also set the colours based on the mime type (text, image, etc.).

<comment><USER22> I'm pretty sure ls does this as well. At least for images and archives

<comment><USER23> Specifically, you list which extensions should get what colors. So it's more like telling ls "Color anything ending in .jpg or .gif in red", as opposed to "Color all images red".

</comment></comment></comment></comment><comment><USER24> > For example, exa prints human-readable file sizes by default (when would you > not want that?)

When I've got two similar but non-identical files, and I think that the difference between their sizes might be important.

That's a silly nitpick, though. It's not like I lose ls by installing exa. Plus, it's a nice excuse to see if I can get cargo working around the corporate firewall.

<comment><USER25> I'll repeat this here:

      export TIME_STYLE=long-iso
      export BLOCK_SIZE="'1"

The first option gives ISO dates, the second the thousands separator. You need a locale for a thousands separator, en_GB here:

      $ ls -on i*
      -rw-rw-r-- 1 1001     1,335 2017-06-16 14:31 icon-shelters.svg
      -rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png
      -rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix

Block size: [https://www.gnu.org/software/coreutils/manual/html_node/Bloc...](https://www.gnu.org/software/coreutils/manual/html_node/Block- size.html)

Time style: [https://www.gnu.org/software/coreutils/manual/html_node/Form...](https://www.gnu.org/software/coreutils/manual/html_node/Formatting- file-timestamps.html)

<comment><USER26> Sadly not supported by BSD ls.

<comment><USER27> True, but if you "pkg install gnuls" and set up an alias, you can get gnu ls transparently.

</comment></comment></comment></comment><comment><USER28> It feels like swiss army knife of 'ls' that tries to do everything in one, and I hope more features are added, such as showing directory size, which would be a killer feature. I hate using 'du' or 'ncdu'.

I installed in Ubuntu (and WSL) by downloading the zip file and also 1 dependency by `sudo apt-get install libgit2-24'

Edit: It's also fast, and I'm beginning to think Rust is really good for making speedy commandline tool, as I'm a big fan of 'ripgrep', another popular tool written in Rust.

<comment><USER29> > I hate using 'du'

Why?

On the other hand, I like to have small tools that do one thing and do it well, and that you can combine to do more powerful things. Personal preference, I guess.

<comment><USER30> In my case the problem is I'm running out of disk space and need to find stuff to delete. So, `du -csh _`. Wow, three huge directories. `cd dir1; du -csh_ `. Repeat. `du -d 3` would seem to be the solution, but it is pretty noisy. I really want something that prints all the "big" stuff in a tree, nicely indented and sorted by size. I end up using a KDE app ported to macOS that shows all the big files in packed rectangles, but can't remember the name.

<comment><USER18> What you're looking for is

      du -hc | sort -hn | tail

No need to visit subdirectories. Throw in a tee /tmp/du.out before the tail to make your life easier.

</comment></comment></comment></comment><comment><USER31> This is cool, but it doesn't solve (in fact, exacerbates) my usual complaint with `ls` - I don't know what the arguments are. The example on the site is:

        exa -bghHliS

Argh! I want to be able to say `ls --size` to get the file sizes. I don't want to remember a million arguments.

<comment><USER32> Completely agree. If the author wants it to be a better alternative to ls, it should have better default. I.e. -bghHliS should be the default options.

<comment><USER33> I guess everyone has their preferences. exa -bghHliS is too much info for me. I agree there should be a shorthand for "give me everything" though.

<comment><USER32> Yes, it's probably too much. But what's shown by default is too little for me.

</comment></comment></comment></comment><comment><USER15> I love it, but it's also kinda angry fruit salad.

Colors are good...too many colors is overwhelming. It _might_ be that I'd come to recognize what the colors mean if I work with it every day, in the same way that I begin to recognize the flow of a program and when a color is "wrong" after using the same syntax highlighting in an editor for a long time. But, I couldn't tell you what any of the colors _mean_ in my favorite editors.

It's more about recognizing when something has the wrong color compared to everything else with that "shape". e.g. a good example is that in shell scripts, I often put space between the var name, '=', and the value. That's not an assignment and can lead to subtle bugs (shellcheck will catch it, too, but I see it clearly in the editor because it doesn't highlight as a variable declaration).

So, what I'm getting at is that I'm pretty sure I'll always have to read the actual text to make any sense out of this output; the huge number of colors may just hinder readability. I don't know this for sure, but it's pretty jarring to look at even with a nice muted color scheme. I love colors in terminals, though, so I'll give it a go.

</comment><comment><USER34> exa is hard to type, bad choice of name for something I'd be typing many times a day

<comment><USER35> I thought the same at first. ls is good mnemonic for list, but what exa stands for and why three letters?

"gf" for example would be better. neighbor characters on the keyboard, could stand for get files.

<comment><USER36> Furthermore, l and s are typed with different hands, which makes it quite fast to type. Exa is all left-handed, so it takes even longer.

<comment><USER37> exa can be typed by using three different fingers. Its not any significantly longer then ls which use two finger movement. Maybe even faster: I dont know what science tells us about such motions, but at my opinion fingers of one hand can be more precisely synchronized, so you really can do faster movements and lower delays between keypresses. Just try to use fingers 2-1-4 (index finger, than thumb, than ring finger) in that order, and you'll see. Or, when typing exa as part of larger text, you can use 3-1-4 sequence of fingers it allows to place palm in a way that allows fast movement into "exa" or out of it, keeping index finger free.

<comment><USER38> Is that how you actually type, or are you speculating? With regular home row typing, e-x-a is 3-4-5, which are the hardest fingers to "drum", and even harder on three different rows. I've tried micro-optimizing special cases like this before, but then I have to think as much about typing as what I'm typing. On the other hand, I know I've hit "sl" by mistake more than a few times.

<comment><USER37> > e-x-a is 3-4-5, which are the hardest fingers to "drum", and even harder on > three different rows.

Its because of the rules of blind typeing courses that says thumb should be used only for space? If you got such a courses more than a year before and already mastered blind typeing, than stop worrying. Just use thumb for `x`.

> I've tried micro-optimizing special cases like this before, but then I have > to think as much about typing as what I'm typing.

It got better with practice. Like blind typeing. All you need is to train you fingers for they do it without conscious effort of thinking. Are you play on some musical instrument? Try it, it teaches how to train your fingers.

<comment><USER38> My fingers are pretty well trained for typing - around 100 WPM, 120 on a good day. As I say, I've tried tweaking my technique for special cases, but it just makes typing more laborious for little or no gain.

It could be different for others. I saw a guy who could do 100 WPM with literally two fingers, although it looked exhausting. A year of waking up with my fingers locked, simultaneously numb and throbbing in pain, taught me that maintaining a relaxed flow is more important than those last 10 WPM. But that means a few combinations like e-x-a will be tap-tap-tap instead of t-t-tap.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> There's only one problem with this thing: all the characters are on one hand with a qwerty keyboard! A bit more annoying than ls, where you can practically hit the keys simultaneously. (You want to nitpick the colors, do you? I'll show you what real bikeshedding is...) In all seriousness, though, it looks good.

<comment><USER40> > There's only one problem with this thing: all the characters are on one hand > with a qwerty keyboard!

They are also all on the left hand in both Dvorak and Neo.

</comment></comment><comment><USER41> I find quite funny that the author is so convinced that the use of colors is the "right default". 1) I'm colorblind so my view of colors is different from yours. 2) I find that any tool which use many colors suck: there will be a color combination which will be hard to read (for example git log: the sha1 keys are dark red on black, unreadable) but using just a few color is very nice (git diff: 3 colors, one for +, one for - and a third one for the rest, nice!).

Also I've seen two times that the color bytes broke something: an expect script was broken by grep's colors and colleagues of mine were very confused when two similar commands gave different output, the reason? Colors!

So colors by default? Thanks but no thanks.

<comment><USER42> My trouble is that most terminals have color settings such that colored text is not very visible. I really wish I could have a large number of different- colored terminals for different tasks, and that is easy if I turn off color, as designing a whole color set that always works is a bigger job.

What's funny is that colored interfaces worked just fine on IBM 3270 terminals in the 1980s, as they did on PCs. I can't understand why we can't get it to work right in the 2010s.

<comment><USER43> Another tricky thing is finding a colour set that works against various backgrounds. A ton of people use either black _or_ white backgrounds. Occasionally you come across a different colour (eg: some people use red backgrounds for 'root' or 'production'), but even if you exclude these folks, getting something that works with both black and white backgrounds is a minimum requirement.

</comment></comment></comment><comment><USER44> The main problem I can think of is that I'm so used to type cd and then ls... But OTOH it's as simple to fix as alias ls=exa

EDIT:

"exa prints human-readable file sizes by default (when would you not want that?)"

I actually use bytes a lot for certain progress calculations.

Also I get an error "exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory" (Ubuntu 17.04)

<comment><USER45> Why does a directory lister need an HTTP parser?

<comment><USER46> This binds to libgit2, which binds to curl. I believe that brings it in.

<comment><USER10> You are correct. exa uses libgit2 for its Git column, and the library's networking parts must still be included when they aren't even being used anyway.

I can see how it looks VERY SUSPICIOUS for a file lister to be parsing HTTP headers! I'm not going to sell your directory entries to advertisers, I promise.

<comment><USER47> For more paranoid folks, it would be nice to have a configuration option to forego the git features and thereby remove the need for linking in any networking code. :)

<comment><USER46> There is one already; it's a cargo feature.

<comment><USER48> I wrote the original Homebrew formula for exa and remembered adding support for the Git-less install, so I was surprised to see it wasn't there anymore! Seems like it was removed in this version bump [1] — I'll open a PR adding it back in.

[1]: [https://github.com/Homebrew/homebrew- core/pull/13676](https://github.com/Homebrew/homebrew-core/pull/13676)

</comment></comment></comment></comment></comment></comment></comment><comment><USER49> The feature I'd be most interested in here is the integration with git, but I don't see an example on the site that demonstrates that. If the author is reading this, could you please add one? (Or maybe point it out, if I'm just missing it?)

<comment><USER50> Yah there's git integration, re read site ctrl+f "git"

<comment><USER51> swift knows that. They're asking for an example of the output of exa in a git repo.

</comment></comment></comment><comment><USER52> >although Rust is cross-platform, I don't have a Windows machine to develop on...

Well, Windows VMs aren't hard to come by and they work quite well on any host platform (contrarily to some other OSes _cough_ MacOS _cough_ )

A native windows version would be interesting, though I believe people generally shun any prolonged interactive use the windows command line, this kind of tool might be one of the possible remedies against the pain of using it.

<comment><USER53> As a maintainer of a CLI program in Rust that runs on Windows, it is mostly a pretty nice experience. The only painful part was getting colors working in both MSYS terminals and cmd/PowerShell based terminals.

I do have a Windows 7 VM setup for testing, but I also bought a cheap Windows 10 laptop to test on as well.

<comment><USER54> You should probably write to exa developer, no? Perhaps, help out a fellow tool developer to bring the goodness of your tools to us devs on Windows? :)

<comment><USER53> It's available as a library: [https://docs.rs/termcolor/0.3.2/termcolor/](https://docs.rs/termcolor/0.3.2/termcolor/)

</comment></comment></comment></comment><comment><USER55> This is really cool - bringing the great treatment of `ack` to ls. And can confirm how fast it is!

The unix philosophy is a great idea, but it doesn't really lead to a good experience. Glad people are making more integrated tools!

Oh, and It's in homebrew already: `brew install exa`

<comment><USER10> When I release a new version of exa, I upload the code and binaries to GitHub, and then someone else whom I have never met but very much appreciate takes it and publishes it to Homebrew, then a few days later I download and start using it.

It's the slowest file copy mechanism I've ever used!

<comment><USER54> You should buy that person a beer if you ever find out who it is.

Plot twist: What if it turns out that it was you all along! :O A la Dr Jekyll Mr Hyde :)

</comment></comment></comment><comment><USER56> Does it take into account the background color of my xterm so things do not become unreadable?

<comment><USER57> I have an unreasonable and unquenchable hatred for developers who assume that their users have dark-background terminals. Honestly, the most insanely passionate contempt.

<comment><USER58> Drives me a bit nuts too, and I would disagree with some of the other things in this page as well (e.g. the preference for "human-readable" file sizes).

But there is a great joy in being able to release a new utility and say about it, "This is how it should work." It reflects your own desires, you understand it, you made the decisions that went into it and have actually thought about the alternatives. There's a delight there. It could be a sign of a piddling egotist, or of a developer who is excited about what real users get to see.

(I did this sort of thing once -- reimplementation of commonly-used, if more niche, thing + manifesto -- from more than 20 years ago: [http://all-day- breakfast.com/wm2/](http://all-day-breakfast.com/wm2/))

My main hope for anyone doing this kind of thing is that not too many people actually use it. You don't want to get stuck supporting a tool like this for the world and its dog.

<comment><USER27> > "human-readable" file sizes).

Nothing is more human readable than "123,456,789", so I think the problem is just the way you go about making them human readable. I couldn't agree more that lurching between B, kB, MB, and GB just because the file size changes it _extremely_ jarring and disconcerting, and actually makes comparing the size _much_ more difficult.

</comment></comment></comment></comment><comment><USER59> > exa is written in Rust, so it's small

I suspected this would be total bullshit, and it is. Its small binary is a mere 3.4 megabytes. I wonder if I misinterpreted the "small" part.

<comment><USER10> I wouldn't say it's bullshit, just a difference of opinion.

38 kilobytes of executable isn't small, it's _tiny_ ; there's no way exa could get to that level without compromising its featureset or development, and even if you did, you'd just have another ls, and we already have ls.

If it's not small, what would you call it? Medium-sized? Something of that size means "download tens of megabytes of runtime and scatter files all over your computer" to me, and exa's smaller than that.

<comment><USER60> > 38 kilobytes of executable isn't small, it's tiny; there's no way exa could > get to that level without compromising its featureset or development

I'd be willing to bet dynamic linking would get it much closer to that ballpark and wouldn't compromise the feature set or development.

<comment><USER61> Dynamic linking to _what_ , though? The features you're looking for have to available in a library for you to be able to link to it.

<comment><USER46> The standard library for one; many C programs have libc dynamically linked. Rust's stdlib isn't.

</comment></comment></comment></comment></comment><comment><USER62> What do all the colors mean? I wish he would make a little page explaining what I'm looking at and what each color means.

<comment><USER10> I know the documentation is currently lacking -- I've been working on a better website that explains all the options and colours for a while now. It should be done Soon™

</comment></comment><comment><USER63> Receive the feedback, but ignore the haters and do what you feel is right for your brainchild.

I've learned some commandline tricks just from reading the comments!

</comment><comment><USER64> Very interesting - thanks.

        /exa/src $ cloc .
            41 text files.
            41 unique files.
            0 files ignored.

        http://cloc.sourceforge.net v 1.60  T=0.10 s (423.5 files/s, 64346.3 lines/s)
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-
        Language                     files          blank        comment           code
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-
        Rust                            41           1152            929           4149
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-
        SUM:                            41           1152            929           4149
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-

</comment><comment><USER65> so whats the replacement for sl in that case? can't live without it

<comment><USER66> Asking the important questions. Maybe exa could show a flying axe?

</comment></comment><comment><USER67> Looks very nice, I've been using K, which has some other cute features ([https://github.com/supercrabtree/k](https://github.com/supercrabtree/k)), but I'll definitely add this to my arsenal.

</comment><comment><USER68> This is cool, I was having trouble with libraries, so I'm switching my main Linux to Arch.

</comment><comment><USER69> A multi-threaded program to list files. The times we are living in...

I'll give it a try for a few weeks.

</comment><comment><USER70> I've been using k [1] to get pretty much the same functionalities but, being written in zsh, it's terribly slow. Your program looks nice but I would love to have an output closer to k in term of colour [2], at the moment it feels way to noisy to me.

[1] [https://github.com/supercrabtree/k](https://github.com/supercrabtree/k)

[2] [https://raw.githubusercontent.com/supercrabtree/k/gh- pages/f...](https://raw.githubusercontent.com/supercrabtree/k/gh-pages/file- size-colors.jpg)

<comment><USER10> I've seen k before, it's pretty neat.

You can't grey out the columns in exa until I land configurable colours, which I hope to get done relatively soonish. But you can use the --colour-scale (or --color-scale) option to colour file sizes based on how big they are. The person who submitted the feature request ([https://github.com/ogham/exa/issues/65](https://github.com/ogham/exa/issues/65)) used k as a direct example.

<comment><USER70> Nice, looking forward to the configurable colours, I feel when everything is in bright colour it makes hierarchy much harder to read.

</comment></comment></comment><comment><USER71> ./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory

Couldnt all the dependencies be statically linked for max portability?

<comment><USER72> Is there a reason it has an http parser?

<comment><USER46> [https://news.ycombinator.com/item?id=14924128](https://news.ycombinator.com/item?id=14924128)

</comment></comment></comment><comment><USER73> This is great. I'm switching to exa!

I had high hopes with this command but found the git features missing: exa -l --git --time-style=long-iso -T

Nonetheless, this displays

Hopefully, the author finds this worth the time to support..

<comment><USER10> Yo. What's it display? Feel free to raise a bug if something doesn't look right. I know it's not the fastest-moving open-source project, but I'll still read everything that people submit.

<comment><USER73> the output is missing the git modification flags

issue: [https://github.com/ogham/exa/issues/183](https://github.com/ogham/exa/issues/183)

</comment></comment></comment><comment><USER74> so... a mix up of the following:

which ls alias ls='ls --color=auto' /bin/ls

tree -L 2

git diff --stat

git status

<comment><USER75> But this is "Modern".

The problem I see with these "modern" command replacements is 1) muscle memory and 2) I have to log into some old systems that simply will not have anything this "modern".

<comment><USER76> An alias in your favorite shell's .rc file solves the first problem. Better yet, you can throw it behind a test block to ensure you never get a command not found error:

        test -f /usr/bin/exa && alias ls='/usr/bin/exa'

The second problem is solved by configuration management tools pushing out your desired tools to your entire environment.

<comment><USER77> > configuration management tools

Which work well until your "entire environment" is some new-fangled ARM/SuperH/(etc.) board, and your configuration management tool is x86_64-only and/or not-in-the-repo of the only distro specialized enough to support that new-fangled board.

</comment></comment></comment></comment><comment><USER78> Is this intended as a full on ls replacement? As in, does it respect the envvars such as lscolors? Will it silently ignore -h, or will it die violently?

<comment><USER79> From the FAQ:

>Is this a drop-in replacement for ls? No — exa has, in my opinion, much saner defaults than ls, so while the available command-line options are similar, they are not exactly the same. Most of the common options will work consistently, though. For example, exa prints human-readable file sizes by default (when would you not want that?) so ls -h no longer applies.

<comment><USER80> > > For example, exa prints human-readable file sizes by default (when would > you not want that?)

When its being used as part of a script.

<comment><USER81> Parsing ls is a pain anyway, using "stat --printf=%s" is much better in scripts, in my opinion.

</comment></comment></comment></comment><comment><USER82> My first thought is that "exa" has all three letters in the left hand. Not nearly as easy to type as "ls".

</comment><comment><USER83> I really dig the very useful output, but I'd also muchly appreciate an `ls` compatibility mode. Thus, one could put something like `alias ls='axa --compat'` into .profile and wouldn't have to re-train their muscle memory. F.e., I'm personally using `ls -altr` very often, and `axa -altr` will yield me an error.

</comment><comment><USER84> Very cool project, will replace ls for exa :)

</comment><comment><USER85> If you want colors, you can use grc to colorize command outputs not just ls, even MySQL terminal.

Some old HN thread. [https://news.ycombinator.com/item?id=3858954](https://news.ycombinator.com/item?id=3858954)

</comment><comment><USER86> I used it now for a year (maybe more, I can't remember) and I find it fantastic. It's great, and I can't imagine using plain old ls any more. No matter what people say, I love it.

</comment><comment><USER87> I already installed & replaced my ls config. Thanks for making it!

</comment><comment><USER88> Interesting that they chose to keep the file name on the right-hand side like ls, and unlike every graphical file manager.

The name is the key field and so it should generally be the left-most column.

<comment><USER89> I guess that's because you can't resize columns interactively on the console, and the other columns are relatively short (and pretty much static length).

It makes sense to list the filename last IMHO.

<comment><USER90> The file name (or entire path) should be where-ever the user expects to find it. Having fixed width columns makes using sort(1) trivial.

For the "all the information" part, I've been using something like this:

      fn () {
        find "${@:-.}" -printf "%TY %Tm %Td %TH:%TM:%2.2TS %1y %4m %3n %4U:%-3G %8s %p\n"; }

</comment></comment></comment><comment><USER91> For a command that gets typed as often as 'ls', choosing 'exa', which is typed with one hand only, even worse, with a repeated finger, is kind of a poor choice.

<comment><USER92>
        #!/bin/bash
        alias lse = exa

</comment></comment><comment> d--b i know this may sound trivial, but I'd probably never use this just because typing exa is a lot more annoying than typing ls. The three letters are on the left side of the keyboard and on the three rows. Sure I could rename it to something I like, but then I won't be able to get used to it, because I won't be able to find it when I log on to other computers. It's a silly thing that has a serious impact on usability...

</comment><comment><USER93> No one invented anything better than Commander-type UI for dealing with files. For non-trivial tasks I'd fire up vifm.

</comment><comment><USER94> This is amazing! Now:

* can you use unicode icons to replace `d` and others with icons of folders and such?

* where are the color signification explained?

</comment><comment><USER95> Surprised no one has suggested replacing permissions display with emoticons.

</comment><comment><USER96> What does "exa" stand for? That's what I want to know.

<comment><USER10> "Like an engineer deeply in tune with his machine, Exa feels the world's component error deep in his bones, fractionally before anything has literally gone wrong." — from Sam Hughes's Ra ([https://qntm.org/ra](https://qntm.org/ra))

It was originally going to be a command-line "file explorer" like ranger, and exa is kind of short for explorer, but I like this quote too.

</comment></comment><comment><USER56> What is the usefulness/learning_effort ratio of this tool?

<comment><USER33> You can pretty much use it like ls for most things, so I'd say very little investment needed.

</comment></comment><comment><USER97> I honestly just like it, colors make it easier on my eyes

</comment><comment><USER98> $ exa -bghHliS ????

How about: $ exa . -- with the same outcome? :)

</comment><comment><USER99> The last thing I want in terminal is colours.

</comment><comment><USER100> Why do you want to replace ls?

</comment><comment><USER101> Nice, I like the -T option.

</comment><comment><USER102> exa is harder to type than ls, but this looks really cool.

<comment><USER103> You could alias it to ls.

<comment><USER104> Or e.

</comment></comment></comment><comment> dan-compton The name is too long.

</comment><comment><USER105> cool. i feel like this whole thread is the epitome of hacker news comments

</comment><comment><USER106> This looks awesome. Anyone's gonna make a PR for ubuntu to add this?

</comment><comment><USER107> Wow I'm quite overwhelmed by the colors

</comment><comment><USER108> ohh i thought exa was a replacement for the word 'is'. i was like damn.... that's fucking cool.

</comment><comment> git-pull While it's not the intention to replace the binary itself, I'm just not a fan of the idea of substituting _system built-ins_ in everyday behavior. Stuff like cd, ls, etc. I like to keep it to the basics.

Even just with PATHs or aliases, or a new binary entirely.

And I'm a person who is no stranger to dot-configs. I've never taken it as far as Z(1), [https://github.com/rupa/z](https://github.com/rupa/z).

A system builtin is stuff you'd see stowed away in /bin. They are essential low level binaries you have to trust. If somehow a malicious ls got out there, nothing's stopping people from writing memory-safe malware that uploads your $HOME configs to some server in a far away land.

The more I say this, I guess defaulting to a substitute for a builtin command doesn't matter. The average developer relies on so much third party stuff in their shell, vim, package manifests, and so on that all these years could have done bad stuff, nothing has happened.

Maybe it's my defense mechanism firing that my own dot-config has grown so big I don't remember what the hell's in it anymore.

In fact, it's a common thing for terminal applications to accept environmental variables to use third party applications. For instance, $EDITOR, and less often (but no less useful): $PAGER. You can give it a shot with most(1) [1], I mention it in my book, _The Tao of tmux_ [2] (available free to read online).

So also, regarding $EDITOR, if you prefer that being in GNU nano, Pico, Vim, or emacs, set it in your .bashrc/.zshrc:

export EDITOR=vim

Also, for git's editor, I don't remember if it falls back to $EDITOR, but you can do:

export GIT_EDITOR=vim

Another tool at your disposal for ls(1), which even FreeBSD supports, it $LS_COLORS:

[http://man7.org/linux/man- pages/man5/dir_colors.5.html](http://man7.org/linux/man- pages/man5/dir_colors.5.html)

edit: actually, BSD's ls(1) seems to be $LSCOLORS ([https://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1](https://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1)):

[1] [http://www.jedsoft.org/most/](http://www.jedsoft.org/most/)

[2] [https://leanpub.com/the-tao-of-tmux/read#leanpub-auto- read-t...](https://leanpub.com/the-tao-of-tmux/read#leanpub-auto-read-the- tmux-manual-in-style)

<comment><USER109> It's not overriding anything, so you're ranting against a faulty premise. The command is called "exa", not "ls", and it isn't even a drop-in replacement -- it doesn't have the same flags. You can't alias "ls" to it.

<comment> git-pull I don't see it that way.

The focus over the qualifier of whether it's "drop-in" misses the point. How else are people going to interpret and use "a modern replacement for ls", in practice?

Not to replace the file /bin/ls itself. Users will symlink/PATH/alias exa in as "ls" _in front_ of /bin/ls in their shell for convenience.

<comment><USER109> So? Nobody is going to use this to replace "ls" in scripts. Are you really arguing against the creation of competing tools? "ack" shouldn't exist because "grep" already exists? "htop" shouldn't exist because there's "top"?

<comment> git-pull Correct, you don't need this tool.

Put it this way: Think of it like a Socratic dialog. Just because a replacement for ls(1) may not be beneficial due to configuration and customization already being commonplace, isn't the same as saying the mere notion of a competing unix CLI tool is bad.

top(1) doesn't allow color configuration. I use htop(1), and like it.

ls(1) already has color customization via LS_COLORS and long-list format via -l in ls. And about 10+ other output options. It's quite flexible.

git status can be shown via `git status`, and via the PS1 in oh-my-zsh/pure.

> Nobody is going to use this to replace "ls" in scripts.

I'm concerned they will, and not recognize it. To beginner and novice shell users, it's easier to cargo cult stuff in and not know what's happening. And things will break in ways that's a nightmare for them to troubleshoot.

My gut instinct is being verified by comments in this thread mentioning alias'ing in exa as ls.

<comment><USER110> If anyone is silly enough to alias to exa, then their scripts will fail. A replacement doesn't have to be a drop in. Server admins who alias it will pay the price, so they won't do it.

</comment></comment></comment></comment></comment></comment><comment><USER111> i'm not going to be rude or hate exa, it looks really cool actually. I, for one, love the color coding. But trying to replace something as old and known as 'ls' probably isn't a realistic goal. I think talents would much better geared towards something missing, instead. Either way, keep up the good work.

</comment><comment><USER112> > Git support: View the staged and unstaged status of every file, right there > in the standard view. Also works in tree view.

This is nearly impossible to implement securely.

Better don't run exa against untrusted directories.

<comment><USER46> It uses libgit2 for this; I don't know what specific attack vector you're thinking about though.

<comment><USER113> Git's on disk format has a massive attack surface.

Do not run "git" in untrusted directories. It is not hardened against that (as opposed to the network protocol).

That probably includes libgit2 unless it explicitly states the opposite.

</comment></comment></comment><comment><USER114> To the author: As you are already making a much more user and human friendly version of ls (like making ls -h the default behavior) please consider placing the name of the file on the _left_ most column

       inode Permissions Links  Size Blocks User Group Date Modified Name

21214836 .rw-r--r-- 1 9.4Ki 24 ben staff 29 Jun 16:16 Cargo.lock

As a human I first care for the _name_ , Currently I'm forced to scan the right most column (which position varies) and then travel back to the beginning of the line and read the rest of the metadata

<comment><USER104> It's much easier to deal with line breaks. File names first would break the entire layout when one of them is too long.

And when the terminal is on the left, you don't have to move your eyes so much away from the middle of the screen.

</comment></comment><comment><USER115> Color is one of the first things I turn off. So many tools color files in ways that are very difficult to read (dark blue against a black background, really?)

I'm colorblind, too, so your red/orange/green distinctions are utterly wasted on me. Raw color is a very flaky and low fidelity way to communicate to a user.

Animation, on the other hand: Give that super important file that's somehow busted or very active some kind of blink or a meaningful animation and you'll have my attention. I may hate the tool for it, but you'll have my attention...

<comment><USER27> No idea on earth why you are downvoted. My sympathies for your challenged vision. Your objection is well founded, and your suggestion has merit.

<comment><USER104> Judging the use of colors in software as a colorblind person is like rating shoes when you have no legs. He's coming across whiny and pretentious.

Sorry it doesn't work for him, but colors are generally useful when working with lots of text.</comment></comment></comment>


A Whitewashed Earthsea - <AUTHOR> http://www.slate.com/articles/arts/culturebox/2004/12/a_whitewashed_earthsea.single.html

<comment><USER2> If she didn't want them to have her permission to do this, she should have insisted on a faithful adaptation or be prepared to turn down the offer. She should have known better than to trust the people involved – that can change at the drop of a hat, and everyone in the business should know this by now.

Sure, it's a bad movie, and she has the right to complain about it. But she also took the money.</comment>


2014: The year the Americans broke the internet - <AUTHOR> http://www.thedrum.com/opinion/2014/01/18/2014-year-americans-broke-internet-good <comment><USER2> There have always been multinets even if it seemed like one over-arching Internet, but users and technology are just going to have to become more sophisticated. Some good folks will be lost along the way to criminals and "intelligence services" (but I repeat myself!) We can't give up the dream and that remarkable goal of networked computing and communication and information accessibility.

It took some time but the assholes got their shit together. Which is what we're seeing now. These assholes have always been with us throughout human history, causing problems and violence and bringing out the worst in the rest of us.

So we need to maintain vigilance, and work early to undo their harm they cause to us and themselves. I forgive them, because they are born with hearts of fear and that will never change. We can't allow them to dictate our lives though. We know what's right and what's wrong, and we simply need to make sure they are put in the sandbox to play with their toys where they can't hurt anyone else while we move forward together as a family.

This is why no one individual should have too much power over anyone else, and no office or government should be similarly afforded the powers to destroy on a whim. There will always be these folks with us, and if we offer them opportunities to express themselves, they will to our shame and regret.

(I know, lots of "theys" and "us." I invite you to take a chance and perhaps expand your mind.)

<comment><USER3> > I forgive them, because they are born with hearts of fear and that will > never change

I think it's not 'hearts of fear' but 'laserlike focus on maximizing shareholder value, greater good be damned.'

<comment><USER4> I think that comes from a place of fear in a lot of people. Money is power, and protection. What does money ultimately buy us if not safety? Perhaps not always literal physical safety, but the safety of knowing you can live life as you see fit without restriction.

Basically, money buys contentedness, and those that remain bound to contentedness are often there through the avoidance of the things that cause them fear.

</comment></comment></comment><comment><USER5> I fail to see how this breaks even the US Internet. Comcast will never cut off the flow to certain parts of the Internet for the sake of charging you to go there. They'll always let you go to those places, they just won't let you go there as quickly if you don't pay extra.

I don't think I have to tell you all how shitty this would be, but it's not a "broken" Internet. We can sit here and concoct all kinds of worst-case scenarios, but we could also do that with anything. Your babysitter _could_ feed your kid a bottle of aspirin - this is within the realm of physical possibility, just as it's within the realm of physical possibility that Comcast starts shaking down websites.

And before anyone even brings it up, Netflix and Comcast's peering agreement has _nothing_ to do with net neutrality. Without peering, Netflix's path to consumers was long. With peering, it's not, which leads to faster speeds. That's it. Peering agreements have existed for many years, and will _need_ to continue to exist for the Internet to continue to exist. It'd be _much_ worse for the Internet to abolish all peering agreements in the name of neutrality (wtf?) than it would be for the FCC to have no teeth in enforcing net neutrality.

<comment><USER6> If deliberately congesting links to _encourage_ another company (who happens to be a competitor) to negotiate peering is not a violation of net neutrality then we need to update the definition.

<comment><USER5> Their peering agreement lapsed, that's all.

Nothing "deliberate" about slowing Netflix down, that's just what happens when packets have to travel further and through the greater Internet.

Put the pitchfork away.

<comment><USER3> Since when does an ISP negotiate peering agreements? It seems like a conflict of interest there, when Comcast's trunk business is actively thwarting the internet delivery service part of the business.

It's like McDonalds charging their _suppliers_ because they're 'sending a lot of product into our kitchens.'

<comment><USER7> > Since when does an ISP negotiate peering agreements?

Since "forever"? When I ran an ISP in '95, peering was pretty much top of the agenda from day one given that bandwidth is such a huge cost centre. The only reason we never tried to charge site providers for peering was that we didn't get large enough before we sold our dial up customers.

> It's like McDonalds charging their suppliers because they're 'sending a lot > of product into our kitchens.'

That's a horrible analogy. Comcast is not selling the chicken, they're selling access to the local roads that gets you to the freeways that can get you to the McDonalds, or any other business. Comcasts customers are not paying for a specific level of access to McDonalds.

But since you're using that kind of analogy, many suppliers _pay_ for shelf positions in large super market chains, for the same reasons site site operators sometimes pay ISPs for more direct access: both sides know who is most dependent on the improved access.

</comment></comment></comment></comment></comment><comment><USER8> Any U.S. decision on net neutrality can only affect the part of the internet that's within the U.S., so outside the U.S., the internet remains as it always was. I'm surprised that the author, writing from the U.K., thinks of "the internet" in such a U.S.-centric way. Did the Great Firewall of China also "break the internet"?

<comment><USER9> for people in China? In a manner of speaking: Yes.

</comment></comment><comment><USER10> Note that I've seen VOIP latency increase in the wake of a cable-company deploying a phone option. Disguising the nature of the traffic caused the latency to drop again.

<comment><USER11> How do you disguise the nature of the traffic without also changing the route taken by the packets?

I would be inclined to test this with/without a VPN connection, but then I wouldn't know whether the improvement was due to avoiding throttling/whatever, or just that my VPN server has better quality routes to the VoIP endpoint.

I guess if you VPN to the VoIP server itself, then it would be a fair test.

<comment><USER10> All RTP seemed to exhibit the issue, so we just setup a test with two RTP endpoints. We wrote a very simple UDP mangler/demangler (XOR with a fixed key) and ran it on both ends of the RTP connection.

</comment></comment></comment><comment><USER12> I've said this in a different argument, but it bears repeating: The "internet" is merely a software abstraction. It doesn't exist. What actually exists is a loosely-coordinated group of private networks, subject to the whims of the owners of those networks. Nobody "broke" the internet, because there was nothing to break. All that's happening is that the abstraction is becoming less representative of the reality, for various quite predictable reasons.

<comment><USER13> You speak only of the letter and not of the spirit of the thing. This has nothing in common with the mentality that created the internet in the first place, which was cosmic and adventurous and poetic.

It reminds me rather of cutting the perforations off of postage stamps. I doubt that J.C.R. Licklider would approve.

<comment><USER12> Undoubtedly there are lots of high-minded poetic idealists behind the development of the internet. But the universe doesn't owe it to them to make the physical nature of the world adapt to their ideals. Maybe many people imagined that the internet would be this borderless space in the ether where packets flowed unimpeded from any source to any destination. Yet, borders are one of the most fundamental facets of earthly existence, and whoever controls them, whether they be nations or network providers, have tremendous power. And that is the true nature of reality.

<comment><USER13> "True nature of reality"? Highly debatable! Maybe in legal offices. :)

Everybody sees that concept through their own filter. I suppose to a cobbler the true nature of reality is surfaces that wear out over time.

<comment><USER12> Try walking all over your neighbor's lawn and get back to me about whether borders are a concept everyone sees through their own filter.

<comment><USER13> Depends on the neighbor.

In any case, filters that happen to be shared don't thereby become the "true nature of reality".

<comment><USER12> Borders are not a mental concept. They are empirically verifiable things (testable by walking across one and dodging the resulting bullets). The fact that you don't believe in them doesn't make them go away.

<comment><USER14> Bullets do not fire themselves, and the person who does so is acting on a mental concept.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> "The Year Multinational Corporations with Powers Beyond the Scope of Individual Actors Broke the Internet" just isn't as catchy a title, huh?

</comment><comment><USER16> >The year _the Americans_ broke the internet.

Yeah... you're welcome, I guess?

I suppose I should have called my representatives, right? Well, their interns, at least...

</comment><comment><USER17> Anytime someone says something like, " and I don't want to add to the hyperbole already out there, but," I write them off.

That is an admittance to using hyperbole, and therefore invalidates the argument, correct?

<comment><USER18> It's up there with "I'm not a racist, but..."

Doesn't affect facts, though. Just means be more sceptical...

<comment><USER19> For a while, the Something Awful forums apparently word-filtered "I'm not racist, but" to appear as "I'm extremely racist, and"

</comment></comment></comment><comment><USER20> I heavily disagree that the internet is now forever broken as this writer is mentioning. One year the U.S. can take one stance, but on the next year they can take another. The whole notion of being broken "For good" implies 'forever' and forever is a lot longer than the writer may realize.

People will know and figure out if ISPs are in fact abusing their powers. Yes, I agree that all ISPs are evil in their own way and there is nothing we can do about that. Although, I think that the ISPs know that they are making more money off of their users than they would throttling other sites thus retaining those users is of the utmost importance.

<comment><USER21> > One year the U.S. can take one stance, but on the next year they can take > another.

Or even the same year; the FCC is already moving to restore (and perhaps expand by voiding barriers to municipal broadband) the substance of the ruels in its Open Internet Order, under different legal authority, based on the decision in the _Verizon_ case. [1]

[1] [http://www.fcc.gov/document/statement-fcc-chairman-tom- wheel...](http://www.fcc.gov/document/statement-fcc-chairman-tom-wheeler-fccs- open-internet-rules)

</comment></comment><comment><USER22> > It is much more than that. As the LA Times said in the aftermath of the US > Appeals court decision that the Federal Communications Commission (FCC) > could not establish rules promoting net neutrality: bow down to your new > internet overlords, Comcast and Verizon.

I'm hoping Google will lead the way and provide a genuine alternative for retail Internet access, given the extent of their parallel network. Comcast and Verizon will then have an opportunity to learn that customers are people to be served and not cows to be milked.

<comment><USER14> Why would Google's alternative be neutral when there is no rule saying it has to be?

<comment><USER22> That's a good point. In terms of an ideal solution, the answer would definitely be "no." In terms of the behavior of the companies involved, I trust Google slightly more than I do Verizon or Comcast to keep the interests of consumers in mind. But trusting a for-profit corporation with something like this is not an ideal long-term arrangement.

</comment></comment></comment><comment><USER23> Not 2014. It was 2001.

When Americans broke theirselves, because of being unable to make anything but guns. And war.

They (You?) broke their own freedom, because of guns, and making money in wars.

Try something else, something new.

</comment><comment><USER9> as much of a pessimist as I am, I highly doubt much of the doomsday scenario will come to pass. Comcast and Verizon will likely spend a lot of time and energy staying JUST on this side of the FCC's ire, because the FCC will always have the "nuclear option" of reclassifying the ISPs as common carriers.

Besides, ISPs degrade/prioritize traffic all the time through management of peering relationships. All they have to do is fail to adequately upgrade the servers that communicate with Netflix to cause congestion while at the same time spending lots of resources making sure their peering relationship with Hulu is top-notch. This would create much faster Hulu traffic relative to Netflix traffic on provider's network, but all of the traffic is still reaching the end-user in the same manner, i.e. it's still "net-neutral".

The only real solution here is the common carrier reclassification because the only real problem is the last-mile-monopoly. Everything else is just business.

</comment><comment><USER24> I'd just like to point out, this also gives an opportunity (or at least incentive) for different forms of internet transport (i.e. googles loon).

<comment><USER25> I'd surmise that forcing the FCC's hand on a common carrier ruling might be preemptive to loon or another mesh-networking based co. gaining ground in a regulatorally permissive space. Especially given longer range wifi tech is on the horizon.

</comment></comment><comment><USER26> More like US Appeals Court broke internet

</comment><comment><USER27> Hey, it was ours to break.

<comment><USER28> lol, yeah, everything is american, i forgot...

<comment><USER12> Stuff created by our defense department in conjunction with our universities certainly is American. To this day, ICANN operates under authority delegated from the U.S. Department of Commerce.

<comment><USER29> By that same logic, all websites are European (Swiss? French? German?) because HTTP was invented by Tim Berners-Lee while at CERN.

<comment><USER30> Just keep those websites off my lawn</comment></comment></comment></comment></comment>


To All the Rejects - <AUTHOR>

Hello fellow applicants, just received my rejection email at 4:03 PST and it is quite a relief. I've been muddling about for the past several weeks anticipating a reply and I'm glad I've finally received one. I've noticed many of the posts regarding the rejection/acceptance emails have indicated that they are relieved once they receive either one. Sometimes I feel like our team kind of hedged our bets on the prospects of the YC experience. It's almost as if the time between applying and waiting had taken a little of the motivation out of our work ethic. But now its over! The dirty, uncomfortable feeling of uncertainty has finally been washed away and there's only one direction from here, forward. Congrats to those who got past the first round. Big chin up for those who tried. And an even bigger chin up for those who will be posting something like this about 2 weeks from now.<p>And lastly to all the rejects, be one of the startups that sends YC one of those "we want to learn from our mistakes" emails. <comment><USER2> Lousy kind of relief, huh? :) How about fighting back? <http://news.ycombinator.com/item?id=3850511>

</comment><comment><USER3> Couldn't have said it better myself, which I did a moment ago on another thread. Onward.</comment>


How does caarzonrent got 3 karma in 1 hour of account creation - <AUTHOR>

How does the caarzonrent got 3 karma for his account with an hour of his account creation. https://news.ycombinator.com/user?id=caarzonrent<p>Was able to a submission too. <comment><USER2> There are no minimum karma requirements for posting.

Accounts start with 1 karma, the submission got 2 upvotes so that makes 3 karma total.

I thought the submission was spam and flagged it, I won't speculate as to how it got 2 upvotes.

</comment><comment><USER3> AFAIK submissions do not need minimum karma, and 3 people clicked the "upvote" button on this submission (thus, 3 karma).

It might also be more people clicked upvote, but some other users downvoted it.

<comment><USER2> You can't downvote submissions. Afaik flagging does not affect karma.</comment></comment>


Code review review is the manager's job - <AUTHOR> https://hecate.co/blog/code-review-review-is-the-managers-job <comment><USER3> The manager can do code review if they're a player-manager. If they're a people manager, it's a lot harder to meaningfully review. Managers usually hired in to manage after the team grows (and splits), rather than trying to convert developers into managers, so they may not have a good idea about the code at all.

I'm more inclined to think that it's senior technical responsibility to review, since they'll have a lot more knowledge of the codebase, its evolution and future direction, potential gotchas and various cultural dos and don'ts.

For sure, it's important to keep an eye on the code review culture, though. It's easy for code review to degenerate into nitpicking small things like whitespace, naming, coding conventions - these should be handled by tools instead. And of course if people are being assholes, they need to be pulled up on it.

<comment><USER4> If your team has pure "people manager", run!

<comment> jon-wood Recent experience has taught me to think of those type of people as delivery managers, rather than people managers, and so long as they understand the limits of their knowledge they can be invaluable.

I've worked with two people who were excellent in that role, they work with the rest of the business to clearly define priorities, and to ensure they understand what we can and can't deliver. When it comes to hard technical decisions they delegate to technical leads and developers, but they have enough experience of engineering to be able to intuit whether what they're hearing makes sense.

I've also worked with someone in the same position, but without the self awareness to know where his knowledge ended and it was time to delegate. That was possibly the worst six months of work I've done, but thankfully he was eventually forced out by the board.

</comment></comment></comment><comment><USER5> The author tried to be clever with the title, but failed to take into account how human perception works. The second "review" gets filtered out like that gorilla in the basketball video.

<comment><USER6> Oh my gosh...I didn't even realize the word repeats...

<comment><USER7> holy shit - got me too!

</comment></comment></comment><comment><USER8> Yeah, I see more projects with bad code review culture than good. There are many things that managers can do about it.

* Assign enough time for code reviews - otherwise developers will just care about their own code submissions and let reviews rot.

* Establish productive code review rules. E.g. always go from big picture to details, otherwise you'll waste time on details that you end up throwing away.

* Make reviewers co-responsible for the quality of code reviewed, otherwise instant acceptance for everything becomes attractive.

<comment><USER9> I just left a job with a truly toxic code review culture.

\- managers would swoop in and leave incorrect criticisms. Asserting plainly false things and in one case reviewing python code as though it was JavaScript.

\- devs would make conflicting requirements for improvement. Dev A demands change A. Dev B wants change B. A and B are incompatible and neither dev will back down. Management of course refused to help settle the argument.

\- change requests completely unrelated to the PR being reviewed would get crammed into the PR. So every small code change could balloon into weeks on refactoring work.

\- Often times code review comments were made without ever reading the code being reviewed. Such as a comment of "Why aren't you using library X?" sandwiched in between invocations of library X.

The culture was clearly rewarding people for shitting on others work instead of doing any work themselves. Getting even the simplest code changes past required endless meetings explaining the most basic facts about computers.

So glad to be gone from there.

<comment><USER10> >devs would make conflicting requirements for improvement. Dev A demands change A. Dev B wants change B. A and B are incompatible and neither dev will back down. Management of course refused to help settle the argument.

This was a problem in my previous job. Options I thought of:

1\. Get a moderator. This is what we did. He did not just settle disputes - <USER2> did more than that. But it's good to have at least this role.

2\. Have a total of 4 reviewers review the disputed section. If there is a majority, change it. If it's a 2-2 split, just leave it as is. (Team did not accept this).

3\. Disputed code (whether changed or not) should have comments saying this vs the alternative was discussed in a code review. Why? Because if there isn't consensus, over time, people are going to keep changing those lines of code back and forth (some developer who was not involved in the review will decide to refactor - rinse and repeat).

</comment></comment></comment><comment><USER11> Before jumping in with your thoughts on how managers should or should not be involved in code review, note that this is about code review review. Reviewing the code review process, and reviewing the code reviews.

<comment><USER12> Hoping there will be a thought leader who will show us how to conduct code review, review, review.

<comment><USER13> His name was Andy Grove.

</comment></comment></comment><comment><USER14> I agree with this in principle. Gets a lot tougher in practice, though.

"Manager" really shouldn't be a job in tech, at least when it comes to individual teams. Management should be a skill, just like all the other dozens of skills tech teams manage in various ad-hoc ways.

Groups of teams plays out differently, since you're really starting to work at the meta level. Even then, though, management is just one of a bunch of skills necessary. (At that point, however, it may be so much of a primary skill to warrant a separate role)

<comment><USER15> > _Management should be a skill, just like all the other dozens of skills tech > teams manage in various ad-hoc ways._

I would phrase it as "like all the other dozens of skills tech teams half-ass in various broken ways".

<comment><USER14> I think an important point in modern technology development is that to make anything of value happen, you constantly deal with dozens of various silos, each of which can be a lifelong specialty area. You have to learn to skim most of the time and be able to dive deep -- a bit -- as necessary.

We may be saying the same thing, but I like my way better :)

<comment><USER15> I agree that everyone needs some management skills, but I'm not convinced that most teams can be run without a dedicated manager.

<comment><USER14> Agreed. The same as most teams cannot be run without a dedicated DBA. The question is whether or not the DBA does other things, not whether that skill is needed or not.

If you've got six or seven people that need constant management, you're working at a burger joint, not a tech shop.

If I remember correctly, in the book "In the Plex", Google scaled out to thousands of developers without having a dedicated management slot. (This is a good time to mention that all generalizations are false, including this one)

In general, in the tech world I find the biggest supporters of "X should be its own job" are either the people who do X -- or train people to do X. Customers don't care one way or another. Neither should we. If we need an X, we get one.

<comment><USER16> > In general, in the tech world I find the biggest supporters of "X should be > its own job" are either the people who do X -- or train people to do X

That strikes me as a characterization with more cynicism implied than necessary.

I, personally, routinely support job specialization, even outside my own specialty. Partly, this is bias/solidarity, but, partly, it's that, even though I'm happy doing Y, I don't want to end up spending 20% of my time doing X (and neither does almost anyone else, which they may not admit).

> Customers don't care one way or another. Neither should we. If we need an X, > we get one.

Except that, no, "we" don't get one, not if we've trained ourselves, in the entire industry, to think X isn't its own job. Instead, we get a Z-that-can- also-do-some-X (but may, as I alluded to above, actually not want to do that X, or, as other comments in the thread suggest, can't do all of X).

This is especially noticeable among startup job postings over the last 5 years where Z is programmer and X is either manager or ops (including the sub- specialty of DBA).

How do someone even know they need an X if no X exists in their world? How we talk about things, especially to newer entrants into the industry matters. We should care.

<comment><USER14> I apologize. I believe you may have misunderstood brevity for cynicism.These are systemic problems. There are no bad actors and everybody means well.

I came to HN because it was supposed to be a place to learn about how startups work.

I'm still here years later. One of the things I learned is that you let the market pull your startup. You can't push it. In other words, you _don 't know_ when trying to make something people want where this is going to lead you. Instead you interact with the folks you're trying to help and that interaction drives the things you do.

There is much wisdom here.

The other major thing I've learned in this area, from my own work with tech groups instead of HN, is that people like doing what people like doing. That is, given their druthers, people will always drift back to doing certain types of things. Like making reports? I'll bet you we can take you out of this job, put you somewhere else in a completely new surrounding -- and in a few years you'll be doing reports. It's what you like doing.

We tech folks are really smart people, so we've managed to take everything we've touched, split it into smaller pieces, and make them complicated. It's what we like doing. Over many years, this means that any significant tech effort contains dozens of skillsets, all of which can be very complex. This number continues increasing.

So with limited resources, as a small org or startup, you're faced with either letting the job drive out what skills you have to learn/use -- or not getting the work done. In larger companies, you can have the illusion that somehow you just need to grow enough experts. Small efforts can't do this.

>>How do someone even know they need an X if no X exists in their world?

Because X is a skill, not a role. If you transition from "jobs require these roles" to "jobs require these skills", and you let the problem drive your learning and adaptation, it all works out. If not? Overhead and friction increase as the required number of people increase, leading quickly to very slow projects. Everybody gets a role where they do what they want, but it's at the cost of focusing on the value instead of the employees.

We naturally tend to view tech development backwards from what it actually is. So good people, doing their best to help folks, end up creating interwoven problematic nomenclatures, policies, and systems. Hopefully that sounds less cynical.

<comment><USER16> > I apologize. I believe you may have misunderstood brevity for cynicism.These > are systemic problems. There are no bad actors and everybody means well.

I, too, apologize, as I didn't mean to suggest your were implying malice. I meant cynicism in its fairly strict/traditional sense of presuming action based on (primarily or exclusively) self-interest. Being self-interested doesn't automatically mean someone is a bad actor.

Thinking further, I would object even to the brevity, since it appears to dismiss (or oversimplify) the supporters' motivations.

> The other major thing I've learned in this area, from my own work with tech > groups instead of HN, is that people like doing what people like doing. That > is, given their druthers, people will always drift back to doing certain > types of things.

I absolutely agree, and I also think that, more importantly, the converse applies, hence my remark about people not wanting to do X.

> we've managed to take everything we've touched, split it into smaller > pieces, and make them complicated. It's what we like doing. Over many years, > this means that any significant tech effort contains dozens of skillsets, > all of which can be very complex. This number continues increasing.

I disagree. There seems to be little evidence of it. We may have constantly shifting sub-specialties based on currently popular tools, but, for example, programmers are still programmers.

I don't believe there was ever a time of Renaissance Man tech folks, where the same person could build a computer from silicon and then program it equally competently.

> Because X is a skill, not a role. If you transition from "jobs require these > roles" to "jobs require these skills", and you let the problem drive your > learning and adaptation, it all works out.

I don't get it, I'm afraid. Is there more to "skill not a role" than semantics? Even the statement "jobs require these roles" sounds awkward because its just too many words. The job _is_ the role, so no transition needed. I'm pretty sure it's already understood that the job/role requires those skills, but, more importantly, is primarily (or even exclusively) about those skills. For people who want to do X (as well as for those who want to avoid X, even if they possess some of the skill), that can be important.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> >Code review, whether via a pull request or other means, still is one of the best bang for buck methods for finding defects in code.

I don't find that to be true. It's a good way of keeping code quality in check, which has an indirectly positive effect on catching defects (as well as a number of other positive effects), but it's not a good way of catching defects itself.

<comment><USER18> Author here. The post is largely written from a point of personal experience and philosophy but that's the one statement I'm comfortable saying has empirical backing.

I link to [https://blog.codinghorror.com/code-reviews-just-do- it/](https://blog.codinghorror.com/code-reviews-just-do-it/) in the post which has an excerpt from code complete:

> … software testing alone has limited effectiveness – the average defect > detection rate is only 25 percent for unit testing, 35 percent for function > testing, and 45 percent for integration testing. In contrast, the average > effectiveness of design and code inspections are 55 and 60 percent.

<comment><USER19> As a firm believer in TDD and pair programming, I would caution you that since ultimate goal of programming productivity is unmeasurable, defect rate could also just be a measure of how much slower those practices are.

I don't think that's the case, but really we have no way to prove that it's true. Just a word of caution if you are ever trying to convince someone, it's best to be up front with the possible flaws of those studies.

</comment></comment></comment><comment><USER20> How do these benefits compare to what you get from pair programming? If the pair works well together I think pairing provides more learning and better quality.

<comment><USER21> Code review is (from my point of view) a way to have a second or third person look at the code from a distance, in his own time, with less context than the author. When I write code I'm far into it and stop seeing the bigger picture. When you pair program, I think the same thing happens. Finally there's the end product, which can be looked at from a distance by a reviewer.

While yes, pair programming is preferred over just pushing to master, I think code reviews (and moreover formal code reviews) are better than pair programming for the final OK.

<comment><USER20> How much time do you take for a code review? If I did a full review that really tries to understand the code it would take me close to the time it took to write the code. But I don't get that time. So I pretty much nitpick on some style issues but rarely find any real problems.

<comment><USER22> That's just it, code review done right takes time. If the author spent four hours on a change, I might spend an hour just reviewing it. You have to understand the problem and the solution just as well as the author.

</comment></comment></comment></comment><comment><USER23> Are there any field studies that demonstrate the impact and efficiency of these practices? Is there a body of evidence to support the assertions that are made in this post?

<comment><USER18> Hi - author here.

The quality assertions are the most defensible empirically. I wrote the post at the office away from my bookshelf which was the main thing keeping me from including them up front (flicking through my old copy of code complete now). Capers Jones' "Software Defect-Removal Efficiency" ([https://ieeexplore.ieee.org/document/488361/](https://ieeexplore.ieee.org/document/488361/)) would be the main one on the effectiveness rate of code inspections. I've collected a few other relevant papers over at [https://github.com/joho/awesome-code-review](https://github.com/joho/awesome- code-review)

The second two themes around education and culture come more from my personal perspective and experience - largely from running the engineering teams at Envato and 99designs respectively. My feeling is the educational and safety elements of code review have come up online a lot more over the past couple of years - but that's just my anecdotal view.

<comment><USER23> Some good points - many thanks.

I think that there is a market failure / exec education issue around these point though. The impact of the improvements measured/evidenced is in the maintenance cost of the delivered artefact and the improvement of the process for future delivery. These are "over the fence" issues for the owners of the delivery shop. We need to get it into the bosses minds that they are paying for things that will be either good in the long term or expensive in the long term - I think that there is a lot of hiding and hedging and shifting of burden (to users) that goes on around that.

<comment><USER18> I agree and trying to cover that education gap is what I'm trying to achieve with the post (and the product behind it)

</comment></comment></comment></comment><comment><USER24> This is a really interesting read. Thanks. I have found in my own experience that developers tend to include the same people over and over again in their PRs and what ends up happening is people tend to just "trust" what the submitter has committed. This often leads to PRs that are almost blindly approved. By involving management to keep the PRs as a tool for discussion (social and technical), I think this could be avoided. It's probably also a good idea to mix up the reviewers (a healthy mix of people familiar with the code and those not familiar with it).

</comment><comment><USER25> But is the code review review review the manager's manager's job?

<comment><USER26> Of course it is it is

</comment></comment><comment><USER27> -1 Moving the evolution of a groups code into the hands of the person who works with it the least is an anti-pattern. Driving change from within a team can be facilitated by a manager who reads the group's code, but any manager who thinks they are going to be the judge of what the team is achieving is deluded and overly enthusiastic about their authority.

</comment><comment><USER18> Post author here - logging off to go to bed because it's bedtime down under. Will pop by again in the morning.

Thanks for reading and all your comments.

</comment><comment><USER28> A manager sitting in meetings all day will be poor at responding to review requests. Its the same reason they make crappy oncalls.

</comment><comment><USER29> Please ignore the advice in that article. It's hinged on the false idea that a manager always knows best.

Imagine for a second that the manager is wrong in his/her judgement. Now the developer has to choose between arguing with the manager and risk being viewed as insubordinate or just going along with the feedback and letting the software suffer the consequences.

<comment><USER30> How is an un-self-aware manager ever going to be effective at anything?

The author notes your objection, and addresses it:

"There's a fine line to be walked between managing the pull request process and micro-managing it. What happens within any specific pull request is the domain of the team so you should resist the urge to intervene frequently within the process itself. The behavioural trends in the process are your domain and if you're running a meta-review process well your work will be predominantly behind the scenes."

<comment><USER29> > meta review

Is "meta review" really a value add for software companies? Is this advice for Managers of peace-time companies who can't find anything more valuable to do with their time?

<comment><USER31> I've seen pull request interactions where a moderating authority would have made all the difference.

We mostly accept the need these days to moderate other online social behavior, like on HN, to reduce potential damage from ego/politics. Hopefully the need is lower in a professional environment like SD, but I could still see it being useful when things go off the rails.

</comment></comment></comment></comment><comment><USER32> This is a very good article.

</comment><comment><USER33> On my team we're all managers. We manage ourselves and our output, and we manage our team, team's output and each other by supporting and assisting each other. So from that standpoint I agree. I don't see the need for dedicated managers though I do value our dedicated scrum/agile coach though, who encourages all of that.

</comment><comment><USER34> This is a terrible idea because it will lead to a more hierarchical corporate environment. My manager has been coding for 15 years in the embedded space, but he is rarely on my PRs (unless we happen to be working on an overlapping feature).

At my company, PRs will automerge if at least one reviewer with write access approves and CI checks pass. This is the best way IMO. It's fast, too.

</comment><comment><USER35> No its not, code review is the team's job, including the manager.

<comment><USER11> It says code review review, not code review.

</comment></comment><comment><USER36> This is fine if the manager is also shipping code. If the manager is not shipping code then it's really not cool to do code review. You won't earn respect that way.</comment>


Unix System Programming with Standard ML (2001) [pdf] - <AUTHOR> http://www.mlton.org/References.attachments/Shipman02.pdf <comment><USER2> Standard ML is _almost_ the perfect language—functional-first without all the heavyweight and seemingly endlessly proliferating categorical abstractions which keeps the level of knowledege one needs to be productive low. Plus it's easy to drop into old school imperative code when needed.

The only thing holdong sml back in my eyes is somewhat clunky syntax and the module system—which is great at first but quickly becomes tricky once you start having to use functors.

A modern, reimagined sml that keeps its core while adopting some of the nicer syntactic improvements from other langs in the family and improving the module system would be a god send

<comment><USER3> SML modules are a classic example of a "shadow language" ( [https://gbracha.blogspot.com/2014/09/a-domain-of- shadows.htm...](https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html) ). I'd like to see an ML-like language where modules/interfaces are normal values, functors are just normal functions, etc.

Modeling such a system at the value level is easy enough, but having it run at compile-time introduces some tricky issues (especially around IO).

<comment><USER4> Andreas Rossberg's 1ML is (was?) an effort to unify the module syntax with that of functions and values ([https://people.mpi- sws.org/~rossberg/papers/Rossberg%20-%201...](https://people.mpi- sws.org/~rossberg/papers/Rossberg%20-%201ML%20--%20Core%20and%20modules%20united%20\[JFP\].pdf), [https://github.com/rossberg/1ml](https://github.com/rossberg/1ml))

The module syntax is certainly clumsy in comparison to the rest of the language, and it's not just the syntax - everything about functor arguments is a bit murky.

<comment><USER5> Is ML used in industry? If so, what would be the scenarios/use cases?

<comment><USER6> ML is a general-purpose programming language, and as such its use case cannot be narrowly specified. (They say it's good for writing compilers, but I wouldn't latch on that.)

<comment><USER7> He asked if it was used in industry. This can be answered by looking at job postings or TIOBE.

</comment></comment></comment></comment></comment></comment><comment><USER8> A similar, nicely written book for Ocaml:

[https://ocaml.github.io/ocamlunix/](https://ocaml.github.io/ocamlunix/)

</comment><comment><USER9> Few years ago I took a course by prof. Dan Grossman on Coursera, there was a part about SML and I so liked it (the language and the course). Now I want to read Okasaki's "Purely Functional Data Structures" book and try to reproduce the code examples in SML.

<comment><USER10> Programming Languages by Dan Grossman, I took it too. Pretty good course, and a nice intro to static typing and FP with SML. Also nice: the DrRacket part, I wasn't familiar with lisp/scheme-like languages. Also also nice: how you can tell he doesn't really like Ruby ;)

<comment><USER9> Oh yes, and I can remember the episode when he jumped while explaining some idea in order to make this moment unforgettable. Shame on me, I forgot what idea it was but still remember his jumps :)

</comment></comment></comment><comment><USER11> As someone with absolutely zero experience with ML languages of any kind, would this be the best intro for me to get into it? Or would I be better off with OCaml?

<comment><USER8> Eventually I would learn Ocaml, as it's the more sensible language for most production code (community, tooling, ecosystem, etc.). But there's nothing wrong with learning SML first. 90% of what you learn will be transferable to Ocaml. Starting with SML might help you focus on the "essence" of ML languages rather than getting overwhelmed by the impressive range of options that Ocaml opens up.

The MLton implementation of SML -- while not necessarily the best ML to practice on -- is particularly interesting because it's a whole-program optimizing compiler. It has a reputation for producing very compact, efficient machine code. Having said that, Ocaml is still a comparatively simple language -- compared to say, Haskell or C++ -- and its native compiler is well known for turning out decent and very predictable code (predictable in the sense that you can read some source code and have a decent understanding of what kind of machine code it will get compiled into).

If you decide to learn Ocaml first, but want to stick to "essential ML", I would recommend Jason Hickey's "Introduction to Ocaml" [1] over the more modern "Real World Ocaml" [2], as the latter book introduces every bell and whistle that Ocaml offers, and has a much more ecosystem-dependent focus (third party libraries, third party tooling, etc.). Still a fine book, but I think it emphasizes advanced Ocaml features a bit too much for an introductory text.

[1] [http://courses.cms.caltech.edu/cs134/cs134b/book.pdf](http://courses.cms.caltech.edu/cs134/cs134b/book.pdf) [2] [https://realworldocaml.org/](https://realworldocaml.org/)

<comment><USER11> Great comment, I'll bookmark those!

<comment><USER12> Absolutely recommend following gps advice on starting with sml - ocaml has some... Bumps. But the other option would be to just start with the reasonml dialect of ocaml:

[https://reasonml.github.io/](https://reasonml.github.io/)

And just FYI, reasonml "is-a" ocaml, so you can also build binaries with the regular compiler back-end - you're not "locked" to targeting js.

<comment><USER13> > And just FYI, reasonml "is-a" ocaml, so you can also build binaries with the > regular compiler back-end - you're not "locked" to targeting js.

The full isomorphism is great. I started with the Reason syntax and when I decided I preferred standard syntax[1], I just use formatting tools to convert my codebases in O(1) effort.

1: Because of tool maturity, and the ecosystem around the standard syntax specifically. I wanted to be able to run `dune utop`, but getting that working with Reason was a WIP; and then there's syntax extensions... And docs are in the OCaml syntax, except the BS ecosystem, which is conveniently bilingual

</comment></comment></comment></comment></comment><comment><USER14> Note that despite the origin of the link the book seems to use SML/NJ, not MLTon.

<comment><USER15> Nothing against MLTon, but SML/NJ seems to be in more common use based on my experience with the [SML] tag on StackOverflow.

<comment><USER16> I like to use SML/NJ for development and experimentation, and MLton for final compilation.

SML/NJ is a really nice development environment, and using a different compiler like MLton or Poly/ML for the final compilation forces you to use the more common, standard subset of ML rather than implementation-specific features.

</comment></comment></comment><comment><USER17> Ah, Standard ML. That brings back great memories of my compiler class at University. This was the first functional language that I was truly comfortable with, and a great tool to write our toy compiler.</comment>


The world's largest library of historical European martial arts books - <AUTHOR> http://wiktenauer.com/wiki/Main_Page <comment><USER2> Have a look at the "Treatise" section of this page: [http://wiktenauer.com/wiki/Fiore_de%27i_Liberi](http://wiktenauer.com/wiki/Fiore_de%27i_Liberi)

Expand one of the sections, like Grappling. Every move has a picture and an accompanying explanation. Nice!

<comment><USER3> Wow. This is really good.

</comment></comment><comment><USER4> Please note that as good as this site may be it appears still to be concentrating on earlier HEMA material and there's a lot of interesting stuff in the 17th-19th centuries, for example.</comment>


Show HN: A web component for playing back responsive DASH video - <AUTHOR> http://joinbox.github.io/dash-video/ <comment><USER2> sweet</comment>


Working memory is better after a barefoot run - <AUTHOR> http://sciencebulletin.org/archives/906.html <comment><USER2> Discussion part of the paper itself is much better read than the article.

[http://journals.sagepub.com/doi/full/10.1177/003151251664039...](http://journals.sagepub.com/doi/full/10.1177/0031512516640391)

>It would be informative to conduct a similar experiment with a population of experienced barefoot runners to determine whether they would also experience WM improvements. It is possible that the increased attentional focus may be automated after an extended period of running barefoot. Conversely, barefoot running may be sufficiently challenging that increased attention is always required and thus would even experienced barefoot runners would see an improvement in WM.

This is very good question and the subject itself is interesting.

There is certain type of 'elevated feeling' you get after some intense activity that requires certain amount of conscious and unconscious proprioception. It feels like you have been 'activated'.

The activity may be period of intense FPS-gaming, running barefoot (especially first times), or lifting free weights instead of using weight machines, doing yoga, juggling or martial arts and learning more difficult moves.

The question is if the activity is challenging enough that it can't be completely controlled by unconscious proprioception or is the increase in difficulty level necessary to get same result.</comment>


What to ask yourself when creating a startup - <AUTHOR> http://bitar.io/disruptive-innovation/

<comment><USER2> I think another way to frame this question could be "What are people misusing excel for at work?" You might be surprised at how many companies are running all of their business off of excel. You could disrupt a lot of industries by building something better than excel for them.

<comment><USER3> I seem to recall Patrick McKenzie (patio11) put a similar tip in one of his newsletters.

Any business process that involves people passing around and modifying spreadsheets is an SaaS opportunity.</comment></comment>


Show HN: Translate your content directly from Google Drive with the Unbabel API - <AUTHOR> http://blog.unbabel.com/post/78660646822/translate-your-content-directly-from-google-drive-with

<comment><USER2> Since this is a "shared base" service, are there any controls in place if a client requests some kind of confidentiality?

<comment><USER3> We can make your content anonymous by replacing the proper nouns. What kind of confidentiality were you looking for?

</comment></comment><comment><USER4> Cool, you should try to sell this to community managers working on twitter.

<comment><AUTHOR> hmm.. interesting, what do you mean?

</comment></comment><comment><USER2> How is this shared throughout the translators?

<comment><USER3> Each request is split into different tasks. Each task is routed to a chain of translators until we are confident with the quality of the translation.

</comment></comment><comment><USER5> I <3 u vasco_</comment>


Hurricane Florence live oceanic cam - <AUTHOR> https://explore.org/livecams/frying-pan/frying-pan-cam <comment><AUTHOR> Where are the electrical power and internet connection coming from?</comment>


[OLD VIDEO] Alan Kay on User Interface, The First Mouse & More - <AUTHOR> http://academicearth.org/lectures/user-interface-i-alan-kay

<comment><USER2> Alan Kay makes reference to Doug Engelbart's 1968 "Mother of All Demos."

I show that demo to all the new members of my UX team at work, to remind them of where we come from, and to show some brilliant ideas in computing that still don't work as well today.

In it, he is able to manipulate data without "opening" and "saving" documents, he just writes data as naturally and seamlessly as one might jot a note on a pad of paper.

Also, and this is what really floors me - he is able to share his screen with a remote user, and vice versa - it's built into the system. In 2011, we _still_ need to install software on each machine to do this, and there's no universal standard for the action of simply _sharing your dang desktop with someone else._

Englebart, Alan Kay, Ivan Sutherland, Jef Raskin - all giants. I'm so happy to see their work continue to be studied and celebrated.

Edit: I didn't say, but should have--thank you old_sound for sharing this, I would have never seen it otherwise.

<comment><USER3> And the irony is that I could only wish we were attempting to stand on the shoulders of these giants. We make little effort to move the industry forward and are quite happy just making our fortunes off of it.

Alan Kay is still going strong: VPRI are a fantastic team and they are working hard in some innovative areas.

</comment></comment><comment><USER4> Follow up with Kay's OOPSLA 1997 keynote <http://video.google.com/videoplay?docid=-2950949730059754521> , "The Computer Revolution Hasn't Happened Yet". "The Early History of Smalltalk" <http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html> is background material for both talks.

</comment><comment><USER5> Note: All videos in the course are available in podcast-friendly version on [http://webcast.berkeley.edu/course_details_new.php?seriesid=...](http://webcast.berkeley.edu/course_details_new.php?seriesid=2011-B-26281&semesterid=2011-B)

A whole lot of them on <http://webcast.berkeley.edu/courses.php>

<comment><USER4> In this case the video being shown in the lecture is Part 1 of "Doing With Images Makes Symbols" <http://www.archive.org/details/AlanKeyD1987> , while the video shown in the next lecture is Part 2 <http://www.archive.org/details/AlanKeyD1987_2> .

</comment></comment><comment><USER6> I've seen this demo before but had to watch it again. Alan Key's incredible. He invented the iPad before Star Trek did :)

It also reminded me that I should really get on with learning smalltalk.

Also Brian Harvey's full class is pretty good, haven't watched all of them yet but the guy is a good lecturer.</comment>