Vue.js 3 - <AUTHOR> https://github.com/vuejs/vue-next/releases/tag/v3.0.0 <comment><USER2> Vue is the only one of the most popular 3 frameworks that can easily be used on a minimal basis to sort of "spruce up" old applications by selectively adding it here and there in the templates.

Seems like they should try more marketing and community outreach toward that end.

Gradual adoption is a feature / selling point not many web development frameworks can claim.

<comment><USER3> i'm afraid this is pretty much plain wrong. react and svelte also support incremental adoption, and i dont know angular but i'd hazard there's a way to do it too if you bothered to ask angular devs.

what you're responding to is _marketing_ , which Vue has done an effective job of. thats fine, but it is unfair of you to conclude "Gradual adoption is a feature / selling point not many web development frameworks can claim."

<comment><USER4> I can tell you that not only he is right, but I've used Vue for exactly that purpose before and works like a charm.

You can go pretty far using Vue with a <script> tag before you start needing build tooling.

<comment><USER5> That's not where they were wrong.

<comment><USER6> Look, I've used both Vue and React for this purpose and Vue is just easier to integrate. React can do it too, but Vue places an emphasis on it and it shows.

<comment><USER5> Yes, but that's a different and less flame-baity claim than the top-level's "Vue is the only one".

</comment></comment></comment></comment></comment></comment><comment><USER7> I am impressed how they redesigned both internal architecture and a public API while keeping the users happy. Many well written projects fall into the trap of being a great fit for the contemporary practices but become less relevant over time as the ecosystem changes. Well done, Vue!

<comment><USER8> curious how easy it will be to move from vue 2 to vue 3

<comment><USER9> I am working on this right now on a medium-sized project, and it's deceptively more work than we anticipated. While Vue's component API itself is remaining mostly backwards compatible with Vue 2, most of the "core" supporting libraries have changed their APIs: Vuex, VueRouter and vue-test-utils in particular.

After the package update and some very basic find/replace across our codebase, about half of our 600+ tests had to be significantly updated. If your tests regularly mock a Vuex store or a router, be prepared to be making a lot of updates.

If you're using some of the features being removed (filters, $on/$off/$once, etc) or make heavy use of custom plugins, it's not going to be painless.

Having said that, I love the direction the new API is heading and 95% of the changes we have to make are for the better in the end, so it feels worth it.

<comment><USER10> to be fair though you are doing this in hard mode. to transition an app you should wait for 2.7 to get all the warnings and guides. so good job to everyone that you didn't find it herculean.

</comment></comment></comment></comment><comment><USER11> I am impressed with the amount of energy Evan is pouring in this open source project.

I am curious if he ever experience boredom working on Vue.

I am also curious if Patreon based income is sustainable for the long run. What if there's another new sexy JS framework in the future?

<comment><USER12> > What if there's another new sexy JS framework in the future?

That's how a market works. It's a strong incentive to keep Vue sexy.

<comment> j-krieger The market also isn't as volatile as people make it out to be. The top most used js frameworks (React, Angular and Vue) have been in the top spots for 5 to 7 years now. I guess the market might as well be settled. Of course there are some new comers every year, but they don't enjoy a large market share. Hell, I've not even seen VueJS used once in any serious project in the industry.

React and Angular are here to stay, and there's no changing that.

<comment><USER13> Angular seems to be dying. Svelte is an interesting contender. I think it will be React's main competitor given a year or two.

<comment><USER14> Angular is massive - MASSIVE - within large orgs you will have heard of but which I cannot name for obvious reasons.

The twitterati and hobbyist crowd seem to love react, but anecdotally I've yet to see it used seriously at a BigCo, but Ng+TS is everywhere.

<comment><USER15> Your comment seems to present anecdotal evidence as facts about $framework's popularity. I think that's misleading.

I'm wondering if there's a scraper out there crawling Alexa TOP 1xxx pages for use of specific libraries, frameworks? Maybe that would present a more accurate picture about this.

Also it's often misleading since in any company with more than a few employees there seems to be more than one team of developers which often leads to different frameworks being used in different parts of the company. In $dayJob we use Angular in some legacy internal stuff, React in a rewritten consumer- facing project and preact or jQuery in a different consumer-facing project.

It's not that simple to determine marketshare of frameworks I think. We can just present different numbers and draw different conclusions from it, e.g. number of job postings mentioning specific frameworks, number of downloads in a registry, number of domains using it (assuming one app per domain), number of stars on github or number of people claiming to use it in the stackoverflow survey.

<comment><USER16> A lot of the web isn't publicly accessible. And most .com marketing sites are built on a much different tech stack than the actual product. Example: landing page is Wordpress, actual site is a SPA (be it React/Angular/Vue etc).

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> > Vue 3 has demonstrated significant performance improvements over Vue 2 in > terms of bundle size (up to 41% lighter with tree-shaking), initial render > (up to 55% faster), updates (up to 133% faster), and memory usage (up to > 120% less).

What does 120% less memory usage mean, really?

<comment><USER18> It's definitely not how to show that, but if you follow their link ([https://docs.google.com/spreadsheets/d/1VJFx- kQ4KjJmnpDXIEai...](https://docs.google.com/spreadsheets/d/1VJFx- kQ4KjJmnpDXIEaig-cVAAJtpIGLZNbv3Lr4CR0/edit?usp=sharing)), you'll see the numbers.

The math is like, if it did use 100mb, and now it uses 25mb, that's 300% less, because 25mb is the "100%", and you reduced by that amount 3 times. Odd.

<comment><USER19> Is this the lingo that statisticians/mathematicians use?

I'd just say 75% drop for 100mb to 25mb.

<comment><USER20> No, it's plain wrong. You could say «vue 2 uses 120% more memory than vue3», but vice versa is thus a different percentage (yes, 75%).

</comment></comment></comment></comment><comment><USER21> I was surprised to see an update to a contemporary JavaScript framework to be welcomed rather than boo'd by the average HN reader. That in itself is an accomplishment.

<comment><USER3> the appetite for a credible alternative to a Facebook project is _strong_. also the vue team has done a great job dripping out information over the past 2 years and building anticipation. very little surprises in this release, hence mostly celebration left. you need to go back a bit further in time to find the critical HN comments.

</comment></comment><comment><USER22> Live release announcement with Evan You going on right now:

[https://www.youtube.com/watch?v=Vp5ANvd88x0](https://www.youtube.com/watch?v=Vp5ANvd88x0)

<comment><USER23> I didn't expect him to say "Enjoy the Vue" ha.

<comment><USER22> Programmer _and_ dad-level humor can be a pretty deadly combination.

<comment><USER24> The combination of the two is so dangerous you could say it's dadly.

<comment><USER25> He took the joke father than he really should have.

</comment></comment></comment></comment></comment><comment><USER26> So it looks like Vue releases are all named after anime?

For anyone curious, here's the full list:

[https://en.wikipedia.org/wiki/Vue.js#Versions](https://en.wikipedia.org/wiki/Vue.js#Versions)

<comment> dane-pgp Is that a JoJo reference?

<comment><USER5> It's my understanding that anything can be a JoJo reference if you want it to be.

</comment></comment></comment><comment><USER27> My only wish now is for the TSX experience to be rounded out.

From a reactivity standpoint, Vue has a much more ergonomic/easy to use API for handling component state, effects, and computed values (in my opinion) than React.

But in the last 6-8 months, I've leaned away from Single-File Components because when you want to do something like define a bunch of small components, it's a lot more difficult to do than with multiple TSX functions you can chuck in one file.

So I've been using Vue with TSX, and the experience (in the last few months only, before that was pretty bad) is _okay_ , but not as solid as you'd get with React.

I'm not the only one who must feel this way, because this exists and has a lot of stars:

 _" Reactivue: Use Vue Composition API in React components"_

[https://github.com/antfu/reactivue](https://github.com/antfu/reactivue)

Unfortunately, this is a weird stance to take in the Vue community, almost nobody uses JSX/TSX. Because of this, the development efforts towards it aren't as much a priority.

Overall, I'd rate the experience as "decent" and "totally usable", but I hope to see the DX for Vue's TSX community improve over the coming months.

\---

Edit 2: Disregard the below, this already exists apparently

Edit 1: Having to write two type definitions for Component Props: one TS interface/type, and one as the JS object sucks. That's my one big complaint.

I know it's impossible because props need a runtime value but someone should make a plugin/babel transform to decorate the "props" key from the generic argument here:

       const MyComponent = defineComponent<MyComponentProps>

Use reflection on "MyComponentProps" to set "props" key.

There's another comment below discussing this drawback too.

<comment><USER28> > Having to write two type definitions for Component Props: one TS > interface/type, and one as the JS object sucks.

Uh, you don't have to? TS inference works with the JS objects. There's no need to provide the generic argument here.

Also check out this: [https://github.com/vuejs/rfcs/blob/sfc- improvements/active-r...](https://github.com/vuejs/rfcs/blob/sfc- improvements/active-rfcs/0000-sfc-script-setup.md#with-typescript) (auto- generating runtime types from TS interface)

<comment><USER27> Holy shit, Evan You replied to my comment.

Happy Vue user since 2016.

> TS inference works with the JS objects. There's no need to provide the > generic argument here.

That's totally valid -- I am just being nitpicky and complaining because if possible I'd prefer to do it the other way: TS type -> JS object

> auto-generating runtime types from TS interface

Whoa. Well, that solves that then.

</comment></comment></comment><comment><USER29> Anyone know if Vue 3 is isolated? Like can you use it to make 3rd party widgets and not worry about version conflict like you would with Vue 2?

</comment><comment><USER30> One thing I'm really excited about with this version is Vite (the snowpack type version of Vue that doesn't require webpack). It should make development so much easier.

<comment><USER31> As someone who includes we pack in my build chain in order to use vue but doesn't _truly_ understand it and has never used Cute, can you explain the advantages?

<comment><USER30> This is straight out of the horses mouth:

\- Lightning-fast cold server start \- Instant hot module replacement (HMR) \- True on-demand compilation

This part should be of particular interest to you:

[https://github.com/vitejs/vite#how-is-this-different-from- vu...](https://github.com/vitejs/vite#how-is-this-different-from-vue-cli-or- other-bundler-based-solutions)

<comment><USER31> Thank you.

</comment></comment></comment></comment><comment><USER32> I was hoping for better Typescript support for typing properties, since that is where 90% of our type errors occur. But it seems like you still have to specify the types manually. The example from the manual:

      const Component = defineComponent({
        props: {
          name: String,
          success: { type: String },
          callback: {
            type: Function as PropType<() => void>
          },
          message: {
            type: Object as PropType<ComplexMessage>,
            required: true,
            validator(message: ComplexMessage) {
              return !!message.title
            }
          }
        }
      })

Contrast this with React where this would be something like this (I think; I've never used React):

      interface Props {
        name: string;
        success: string;
        callback: () => void;
        message: ComplexMessage;
      }

      export default class Component extends React.Component<Props> {
        ...

Quite disappointing. Maybe not that surprising given Evan said he only started using Typescript very recently, and many beginner Javascript developers don't realise that they should really be using Typescript (fortunately Evan isn't one of them). I would recommend still avoiding Vue for this reason alone.

<comment><USER28> It's not that we can't implement it like that, the real challenge is in minimizing breakage from v2. We decided it's better to not completely alter how props are declared because that would be too much breakage.

Instead, there's the compiler-based approach with `<script setup lang="ts">`: [https://docs.google.com/presentation/d/1VjBM6ae- fuawK1TltYLX...](https://docs.google.com/presentation/d/1VjBM6ae- fuawK1TltYLXtcXGaxJw1y8ncT6wnbjaBGo/edit#slide=id.g86a2c92822_0_168) (runtime props definitions auto-generated from TS interface)

<comment><USER32> But if the prop definitions are generated at runtime that means Typescript can't check them at compile time surely? Better than Vue 2 I guess but still not as good as React.

Fair enough on not wanting to break things, but I still feel like it is Vue's second biggest flaw and worth breaking to fix.

</comment></comment></comment><comment><USER33> The announcement talk was nice to watch, however, it was technically void of any of the implementation details.

It's interesting to me that they did not consider the approach of pushing more work to the compiler and less to the runtime in the manner popularized by Svelte. I wonder what the trade-off between their current rendering approach and the Svelte-based approach are?

<comment><USER3> > they did not consider the approach

they certainly did, lol. the tradeoff is the same it's been; they want all of vue available in a script tag.

<comment><USER33> Guess I missed that. That makes sense, it's an interesting trade-off though. I suspect that including Vue via a script tag is not how the majority of users implement Vue; and therefore clinging to the virtual DOM may be a net-negative for most use cases. Personally, I am using Vue for a data-intensive app where performance really really matters. Although, I understand how broadening access to the framework increases availability and adoption; and for most use cases these performance considerations don't have any real world implications.

It is interesting though looking across benchmarks though and seeing non virtual DOM frameworks crushing their counterparts in terms of speed. I wonder if we'll see more growth in that space in the future.

<comment><USER34> Which benchmarks? In the js-framework-benchmark Svelte is slower than Inferno or Ivi and only slightly faster than Preact or Vue. [https://krausest.github.io/js-framework- benchmark/2020/table...](https://krausest.github.io/js-framework- benchmark/2020/table_chrome_85.0.4183.83.html)

You may be aware but it's also important to note that everyone is trying to cheat these benchmarks so they don't mean much. The implementations aren't data driven and don't look much like how we'd write real world code. See the discussions here including the linked issues and PRs [https://github.com/krausest/js-framework- benchmark/issues/77...](https://github.com/krausest/js-framework- benchmark/issues/772)

</comment></comment></comment></comment><comment><USER35> I don't really understand the composition API. Doesn't passing values by reference which can be modified anywhere downward the tree make your app difficult to reason and debug it?

<comment><USER27> I have a fairly large/complex SaaS platform built with Vue 3 composition API. Can maybe shed some light.

A while ago I wrote the same component in Vue 2 and Vue 3 as an example of one versus the other:

[https://codesandbox.io/s/bold-shamir- uqm0b?file=/src/compone...](https://codesandbox.io/s/bold-shamir- uqm0b?file=/src/components/Vue2.vue)

[https://codesandbox.io/s/bold-shamir- uqm0b?file=/src/compone...](https://codesandbox.io/s/bold-shamir- uqm0b?file=/src/components/Vue3)

If you meant more from a conceptual standpoint -- the usage patterns with Vue 3 is pretty nearly identical for most people. You just replace "data()" property with some "reactive()" state value in setup (or "ref()" for single values).

You CAN write things like generic hooks/"useXXX()" helpers, but you likely won't wind up with a ton of those.

Also, about the reference passing: it doesn't actually really work like that. If you pass a "ref()" or "reactive()" value as a prop to a child component, and you mutate it there, it doesn't propagate to the parent.

Vue will throw this warning:

        [Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "someRef"

</comment></comment><comment><USER36> I just started vue 3 and its incredible compared to my experience with react. Way to go Vue team!!!

<comment><USER37> > and its incredible compared to my experience with react

Could you expand on this a little more? What is it specifically that makes it incredible compared to React, in your opinion?

<comment><USER36> I like that vue manages dependencies so you dont worry about pure components anymore, but I believe that was fixed recently in react? The biggest thing is I despise writing JSX. To me it just feels absolutely miserable. The upside is that you have incredible fine grained control over the dynamic rendering of components, but so far even in my complex app there's been no need to write a render function yet (similar equivalent in vue to get that same level of control as react).

Also, I really like the data binding which vue took from angular. That was always by far my favorite part of angular, rather than having the binding be written in JS which feels too mechanic to me. I dont feel like I'm writing HTML / front end code, I feel like I'm writing a hybrid mecha mutant of JS + HTML + weird syntax.

</comment></comment></comment><comment><USER38> Ha, I literally just built my first Vue 2.0 project yesterday. I'm already behind! :)

(just a Chrome extension) [https://github.com/FastComments/fastcomments- debug/blob/mast...](https://github.com/FastComments/fastcomments- debug/blob/master/chrome/src/popup/App.vue)

</comment><comment><USER39> I still don't see a reason why one would use Vue or React.

I agree that templating of data is something you should use a library for. But there are great templating libraries. Handlebars for example.

Can someone give a short example of code that would be more elegant using Vue then just a simple template engine?

<comment><USER40> One example is building an application like minesweeper. Would you really want to tackle that with jQuery and templating engine? I'd rather break everything into components, have them talk to each other through a state manger like vuex or redux, and only phone home to my API for important things, like the final game score.

<comment><USER39> I would neither need jQuery nor a templating engine to write Minesweeper.

<comment> j-krieger It's great you applied your vanilla JS skills to his totally metaphorical example.

I still don't get why it's okay for every other programming language to use the STL or huge dependencies, but doing so with javascript is frowned upon for some people. You wouldn't write a JSON parser yourself in CPP, you'd install something from conan or use the STL or boost for that. Why is it so bad to do the same with js?

<comment><USER39> The browser _does_ supply a huge number of APIs.

To set one of the Minesweeper tiles to bomb, you could do:

tiles[x][y].className='bomb';

And you are done. The rendering will nicely take place according to what you defined in the CSS.

<comment><USER36> What are you talking about? You're just talking about simple class manipulation which has nothing to do with actual reactivity, especially 2-way data binding.

How would you support that with your "templating engines" you keep mentioning, which to me doesn't mean anything at all, in my understanding of what a templating engine is like handlebars.

<comment><USER39> As I said, I would not use a template engine to write Minesweeper.

<comment><USER41> So when I click a tile you have some code on the onclick handler to go update the counter at the top? Sounds messy if there are multiple things you need to update when some data changes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> Good to see this out. I want to pick a good frontend scheme for future projects but I don't really need most of the fancy SPAs and the complexity coming with it.

Invested a few weeks on Vue a few months back, then the concern about 'React has 80% market share and you can find React developer much more easily in the west" never went away.

Maybe Mithril is the way out? I just need a really light-weight client-side- ajax MVC for some embedded product webUI, in fact jquery+BT might do the job well but again, jQuery is not modern any more.

Not a frontend guy, picking a direction there has always been challenging.

<comment><USER43> I think what is not mentioned with any of the big SPA frameworks is the amount of time you invest in the churn between versions. After dealing with this in Angular for a number of years, I ended up going with stock JavaScript for my recent projects and could not be happier. Performance is much better. I have a better understanding of what goes into the product. And, I am not constantly dealing with a new version and breaking changes every 3-6 months.

<comment><USER44> That's really an Angular problem; React and Vue have had very few breaking changes over the years.

<comment><USER3> indeed. React 16 celebrates its 3rd birthday next week. ([https://reactjs.org/blog/2017/09/26/react-v16.0.html](https://reactjs.org/blog/2017/09/26/react-v16.0.html))

</comment></comment></comment></comment><comment><USER45> Can I use it by including it with a script-tag?

Vue 2 was kind of possible to get up and running with a script-tag to get components in a pre-existing app.

<comment><USER36> Yes its possible

</comment></comment><comment><USER46> anybody know the status of Nuxt and vue 3 support?

<comment><USER27> It's meant to be released sometime within the coming weeks from contributor comments IIRC.

It works well with the Composition API plugin for Vue 2 though. They have a dedicated package for this.

With the Nuxt VCA + Nuxt TS plugin, the experience is solid IMO.

</comment></comment><comment><USER47> > allows end users to shave off up to half of the runtime size via tree- > shaking

Doesn't webpack support _actual_ tree-shaking (not just modules) or is that still a Rollup-only feature? There should be little difference in size in importing packages vs files if tree-shaking is on.

<comment> j-krieger Webpack doesn't support actual, statically checked tree shaking for now. There is a parameter called ''sideEffects'' you can employ in your package.json, which if switched to off gives hints to the compiler that your code is side- effect free and can thus be eliminated if not used.

</comment></comment><comment><USER48> good timing. I'm about to start learning vue.js so I'll start with this. We'll see how long it takes to "unlearn" 40 years of traditional programming and jump into the world of web apps.

</comment><comment><USER49> I don't know if React could allow set children's data via parent, like

$childRef.setData({ data })

When i see this code in a Vue codebase, my mind got hurt.

I still prefer React due to its consistent reasoning about data flow in the app.

<comment><USER50> That sounds like the equivalent to React's forward refs. [https://reactjs.org/docs/forwarding- refs.html](https://reactjs.org/docs/forwarding-refs.html)

<comment><USER51> No, that's very different, in two ways.

First, `$childRef.setData()` appears to be the conceptual equivalent in React of `childClassComponentInstance.setState({someField})`. While that's technically possible, it's _extremely_ non-idiomatic in React and completely discouraged.

Second, "forwarding refs" is a feature specifically designed to allow a component to apply a ref to something _inside_ of itself. For example, the React-Redux `connect` API uses ref forwarding to allow `<ConnectedComponent ref={instanceRef}>` to hand back the inner wrapped component, not the outer wrapper component from the library. It doesn't have anything to do with calling a state setting function on a component in and of itself.

</comment></comment></comment><comment><USER52> Why is IE11 support still important now? I can't find exact stats on it, but it seems <2%. Surely projects which still want to support IE11 could still stick for a while with Vue2.

<comment><USER53> IE11 is still heavily used in some industries, such as healthcare. Browser statistics services usually don't pick up on a lot of IE11 use because it's on internal networks.

I wish I could ignore IE11, but the reality is that I can't.

<comment><USER54> The point is that Vue 2 can continue to be used though. There's no need to upgrade.

</comment></comment></comment><comment><USER55> I've been confused by some of Evan's presentations about performance gains and other statistics. For example, the release notes say

> updates (up to 133% faster)

How can something be > 100% faster?

<comment><USER56> If you take 100% faster to mean 2x faster (takes 1/2 the orig time), 200% faster to mean 3x faster (takes 1/3 the orig time)...

Then 133% faster means 2.33x faster (takes 1 / 2.33 = 0.42 the orig time).

<comment><USER55> Thanks for clarifying :-)

</comment></comment></comment><comment><USER57> i learned vue2 3-4 years ago.

should i learn vue3 or svelte instead?

<comment><USER58> Depends on what you want.

I researched tech required in job offers and React was first, running circles around Angular and Vue. Nobody spoke of Svelte

<comment> j-krieger Where I live, VueJs isn't even mentioned in any job postings. Large companies still work with older Angular projects, new projects are more often than not done in whatever fits the need.

</comment></comment></comment><comment><USER59> is reactive() just a mere wrapper around ref() ?

<comment><USER27> Kind of -- reactive() lets you declare multiple values at once, and you can read the property directly.

ref() is for single values, and to get at the actual VALUE, you need to use "myRef.value"

       const state = reactive({ msg: "hello", count: 1 })
       state.msg // "hello"

       const msg = ref("hello")
       msg.value // "hello"

Though when you use ref()'s in templates, it will bind to .value for you.

<comment><USER60> I find myself using `const state = reactive({...})` exclusively now. It's just way simpler (read:less mental overhead). But, I've only been using the composition API for a short while now.

Do experienced Vue devs actually use both regularly?

<comment><USER27> Personally, I rarely use refs. I think they have more use when creating general-purpose libraries for Vue.

You can also just call "toRefs()" on a "reactive()" object though.

Refs are also useful if you want to destructure a reactive object without breaking the reactivity, scroll down just below this:

[https://composition-api.vuejs.org/api.html#torefs](https://composition- api.vuejs.org/api.html#torefs)

</comment></comment></comment></comment><comment><USER59> if this means no more Vuex, i'm all for that. that extra abstraction layer never proved useful to me.

<comment><USER61> Out of curiosity, how do you handle data needed by tons of components at different tree depths (info about the current user for example)?

I don't always reach for Vuex, but when an app reaches a certain size it sure beats passing every bit of common data down through the entire tree, as I find you quickly hit a point where you're passing data to components solely so it can pass it to _it's_ children.

<comment><USER62> It's funny I still have never really understood the case for Vuex. So far I have built decent complexity apps just by having a global reactive object that all components link to directly in their Vue data and I have yet to hit a problem. I see huge writeups and design patterns all suggesting I really need to use a state management library and I'm waiting for the day the penny drops and I realise what a mistake I've made but so far everything just keeps rocking along .... what am I missing?

(I get that there are some nice features like time travel debugging etc but none of them seem outweigh the giant additional complexity of routing every single state change through 1-2 extra layers.)

</comment></comment></comment><comment><USER63> Nice, but does it have material?

<comment><USER64> [https://vuetifyjs.com/en/](https://vuetifyjs.com/en/)

<comment><USER63> I dont think this is available for vue 3. Sadly.

</comment></comment></comment><comment><USER65> No Nuxt 3 yet.

</comment><comment> awinter-py hooray <Suspense></comment>


When Making Books Was as Much of an Art as Writing Them - <AUTHOR> https://www.npr.org/2017/11/23/545228136/when-making-books-was-as-much-of-an-art-as-writing-them <comment><USER2> Thanks for the post. Publishing/bookbinding is great.

You might want to try submitting a post, though, that has examples of nicely published/formatted/printed/bound books.</comment>


Introducing Block Decorations - as-cii http://blog.atom.io/2016/02/03/introducing-block-decorations.html <comment><AUTHOR> I've been wanting this feature ever since I watched a video of TempleOS, which featured images in source code (everything is in "DolDoc" format: [http://www.codersnotes.com/notes/a-constructive-look-at- temp...](http://www.codersnotes.com/notes/a-constructive-look-at-templeos/)). I'd love to be able to drop in diagrams, screen shots, and scribbles into the source code of my personal projects!

<comment><USER2> Yeah, I actually started on a package that would render comments as markdown, allowing you to create 'notebook'-style source code. I gave up when exploring the API and not finding a good way to replace lines with (possibly variably- height) content.

There's also the problem that Atom doesn't have any debuggers worth speaking of so far. That could change now.

I'll have a look into this. Sounds great anyway.

</comment></comment><comment><USER3> I find Atom very interesting, but the performance always drives me away from using it. Have recent versions improved? Anyone using it full time?

<comment><USER4> I've been using Atom full time for about a year and a half now. I've never noticed performance issues though, so I've always been curious about where these complaints come from.

I just ran a find over the project I've been working on full time, and the largest file, by a long shot, is 8kb, and a little under 100 lines. That's just an autogenerated enum of the HTTP status codes though, so it isn't indicative of real code.

In the vast majority of cases, all of my files are less than 4kb, and hover around 40 lines or so. Atom handles this use case just fine, and I'm hard pressed to think of a situation where I'd run into performance concerns. The entire process itself is using less than 80mb of RAM, and 0.2% of my CPU. A single tab of Chrome is worse than that.

What are people doing with their text editor that they need blazing speed?

<comment><USER5> Your codebase is very modular and wonderful but for other projects, large files (100kb+) are not uncommon. For those projects, "clean up your code before using my product" is not an acceptable answer.

<comment><USER6> This seems like a tragedy of the commons: those projects only exist in the state they're in because some products exist which allow you to work with them despite their flaws. Whereas, if _nothing_ worked with 100kb+ source files, the projects _would_ change.

</comment></comment></comment></comment><comment><USER7> I love Atom and it's growing ecosystem. I hate that it's much slower (especially startup time) compared to Sublime Text and that it's using often tremendous amounts of resources. I also still wonder: Why CSON and CoffeeScript... in 2016?!

<comment><USER8> I've never done it, but id assume the effort to do a rewrite would be tremendous.

<comment><USER9> Not really, it would be tedious, but idiomatic coffeescript can be converted to idiomatic javascript basically on a line-for-line basis. Also the compiler really does produce readable code (though unmistakeably computer-generated), so the process might even be sped by reducing it to just tidying up compiler output.

It's a task that could easily be spread across any number of human translators, too.

The main limiting factor is the quality of the test suite, which dictates how quickly typos could be found.

<comment><USER10> Along those lines, it would be wonderful if someone would write a coffeescript implementation that output clean, idiomatic ES6 rather than ES5!

<comment><USER11> You can try [https://github.com/decaffeinate/decaffeinate](https://github.com/decaffeinate/decaffeinate). It's basic but gets some work done.

</comment></comment></comment></comment></comment><comment><USER12> Wow ! This is great ! I guess packages ala ipython notebook are coming soon :)</comment>


Jvm performance tuning (notes) - <AUTHOR> http://www.umbrant.com/blog/2012/twitter_jvm_tuning.html

<comment><USER2> I'm the author of this post. Note that it's entirely adapted from the talk done by Attila Szegedi ([http://www.infoq.com/presentations/JVM-Performance- Tuning-tw...](http://www.infoq.com/presentations/JVM-Performance-Tuning- twitter)), who deserves all the credit. I just filled in some of the gaps and reworked it so it flows in textual form.

I'll try to update the post with any comments I get here. It's definitely not ground truth as I was a bit fuzzy on some parts of the presentation.

</comment><comment><USER3> Great article. Note that the point about Strings using 2 bytes per char isn't always true. The latest HotSpot VM has an option called "-XX:+UseCompressedStrings" (see [http://www.oracle.com/technetwork/java/javase/tech/vmoptions...](http://www.oracle.com/technetwork/java/javase/tech/vmoptions- jsp-140102.html)) where the VM will try to use ASCII-strings whenever possible to save memory.

</comment><comment><USER4> > Don't write your own memory manager, and stop if you find yourself doing > something ugly with byte buffers.

What's wrong with byte buffers? Serious question, as I use them all the time whenever I do OpenGL-ES 2.0 surfaceviews for android apps.

<comment><USER5> Well, you don't really have an alternative for that (short of writing your rendering code with the NDK, as I ended up doing).

The overhead of all the crap I had to do just to get coordinates from Java to OpenGL was downright ridiculous.

</comment></comment><comment><USER6> FTA: _Twitter had a service that would have a terrible GC pause every three days. Solution: just bounce the machine after less than three days._

That is not what I would call a solution. It's a _work-around_.

And not a very good one.

<comment><USER7> The context isn't clear from these notes.

Full context as explained in the talk: used to have stop-the-world GC for 2 minutes every hour. After implementing bytebuffer-based slab allocation, this is only several seconds, and once every three days. Service runs on 200 nodes, with redundancies. Kicking the process on _one_ of them, in a slow roll that finishes in under 3 days, works around the unresponsiveness window (planned shutdown easier to manage than an unpredictable pause).

It's _totally_ a workaround and not a solution. Atilla follows up this example with an anecdote of talking to Oracle folks about when are they going to have true pauseless GC, and they responded with "not that big an issue, really, everyone finds a workaround..." So, this is an example of a workaround. A pretty good one once you realize it's not "the one" machine, it's "some one" machine out of 200.

<comment><USER6> Ah - in context, for that problem, I agree it's 'okay'.

Thanks for clarifying.</comment></comment></comment>


Goldman Sachs Says Bitcoin is Not a Currency - <AUTHOR> http://thesurge.net/goldman-sachs-says-bitcoin-is-not-a-currency/

<comment><USER2> If you keep spamming thesurge.net links for articles that are low-quality rewrites from previous websites (in this case, [http://techcrunch.com/2014/03/12/goldman-sachs-bitcoin-is- no...](http://techcrunch.com/2014/03/12/goldman-sachs-bitcoin-is-not-a- currency/)), then you're just going to get the domain banned, as was the case with your previous account ([https://news.ycombinator.com/submitted?id=TheSurge](https://news.ycombinator.com/submitted?id=TheSurge))

<comment><AUTHOR> They aren't exactly low quality and nearly all tech news websites report from the same sources. Additionally we do have original content as well, but thanks for the tip..

<comment><USER2> The article linked at [https://news.ycombinator.com/item?id=7375860](https://news.ycombinator.com/item?id=7375860) is a low quality, analysis free of [http://techcrunch.com/2014/03/09/console- crisis/](http://techcrunch.com/2014/03/09/console-crisis/) which contains the same flaws present in the original. Atleast you could have linked to the TechCrunch article.

The "same source" argument doesn't work here, since TechCrunch used non-recent data and the probability of you _coincidentally_ using the same data for your own independent post is low.

<comment><USER3> Thanks for the feedback. We later corrected our position, and actually disproved the article above after some readers pointed out that the numbers didn't match up in emails to us ([http://thesurge.net/contrary-to-our-recent- post-it-appears-c...](http://thesurge.net/contrary-to-our-recent-post-it- appears-consoles-are-very-much-alive/))

In addition, I've personally updated the article that I wrote on bitcoin to include some analysis of what it could mean at the end of the news report. I appreciate feedback and constructive criticism.

I'm saddened to hear that my account has been banned from posting new articles, though.</comment></comment></comment></comment>


AWS open sources cloud development kit to make Kubernetes easier to use - <AUTHOR> https://siliconangle.com/2020/05/13/aws-open-sources-cdk8s-make-kubernetes-easier-use/ <comment><USER2> Similar idea to [https://www.pulumi.com/](https://www.pulumi.com/), but from AWS and with less languages so far. I'm a fan of being able to use full languages to build declarative representations of the infra I want, as languages like Terraform's HCL can break down if you try to do to much modularity with them.

AFAICT it's good that there are several teams implementing this pattern (not just one startup), but Pulumi is probably more battleworn for now.

</comment><comment><USER3> Link to the toolkit: [https://cdk8s.io/](https://cdk8s.io/)

</comment><comment><USER4> Too hard to use YAML, apparently.</comment>


WebGL Realistic Earth with Carl Sagan quote - <AUTHOR> http://earth.plus360degrees.com/ <comment><USER2> This quote is great, but the visual ruins the context of a pale blue dot. From [0], the reference was to the Voyager probe taking an image of the Earth from near the edge of the solar system and the Earth appears as a dot less than a pixel in size.

From that perspective, seeing majestic images of the Earth larger than life and in your face is contrary to what Sagan was saying. With the outstanding visuals in this demo, one might get the sense of a majestic world full of opportunity, worthy of building armies to conquer and spill blood for each chunk of land; the very antithesis of his point of how tiny and insignificant our world and the people on it are.

The real pale blue dot: [https://upload.wikimedia.org/wikipedia/commons/7/73/Pale_Blu...](https://upload.wikimedia.org/wikipedia/commons/7/73/Pale_Blue_Dot.png)

[0] [https://en.wikipedia.org/wiki/Pale_Blue_Dot](https://en.wikipedia.org/wiki/Pale_Blue_Dot)

</comment><comment><USER3> Why not use the Carl Sagan Audio? Here it is without any music: [https://www.youtube.com/watch?v=K05xxeCdhSo](https://www.youtube.com/watch?v=K05xxeCdhSo)

<comment><USER4> Maybe because they don't know what the Fair Use Act is.

[http://www.copyright.gov/fls/fl102.html](http://www.copyright.gov/fls/fl102.html)

</comment></comment><comment><USER5> Nice. I did a similar rendering about a year ago: [http://operation- survival.appspot.com/html/index.html](http://operation- survival.appspot.com/html/index.html)

With a bit of technical details and ideas of where the project is headed here: [http://blog.buschnick.net/2014/02/webgl- earth.html](http://blog.buschnick.net/2014/02/webgl-earth.html)

</comment><comment><USER6> That was great. I would have loved to have watched with a virtual Sagan narrating -- I heard his voice in my head the whole time.

The lightning on the dark side of Earth was a neat effect. Might want to consider flickering it randomly rather than flashing it to make it feel a little more realistic.

Well done.

</comment><comment><USER7> Should've used one of these as background music :)

[https://www.youtube.com/watch?v=XGK84Poeynk](https://www.youtube.com/watch?v=XGK84Poeynk)

[https://www.youtube.com/watch?v=zSgiXGELjbc](https://www.youtube.com/watch?v=zSgiXGELjbc)

<comment><AUTHOR> These would have totally rocked!

</comment></comment><comment><USER8> Nice work, I've been putting together something like this as well in my spare time, been trying to nail down the right shaders to handle the atmospheric glow as well as morphing cloud layers as they move. Trying to see how possible it is to come close to this effect [https://www.youtube.com/watch?v=Ybh11kcDhfM](https://www.youtube.com/watch?v=Ybh11kcDhfM)

</comment><comment><USER9> It's nice. However text is too small. They should try to mimick TV font sizes, that is huge so one can read them without focusing on the text.

</comment><comment><USER4> Doesn't work on Ubuntu 14.04 in 64-bit Chrome 42.0.2311.90.

No JS errors in console either when clicking "begin".

</comment><comment> white-flame It'd be nice if it to panned out in an approximation of the original pale blue dot picture.

</comment><comment><USER10> Great Job. I liked it. How did you add lightning effects? Is it procedurally generated?

</comment><comment><USER11> Lovely! Very touching...

</comment><comment><USER12> You really should give attribution to Carl Sagan

<comment><AUTHOR> In the title of this post? I will edit it right now. I saw the attribution of Carl Sagan in the credits of the project.

</comment></comment><comment><USER13> This crashed my browser. Firefox 37.0.2.

</comment><comment><USER14> those blue marble 2012 textures are still awesome.

webgl thing, okay for a mist shrouded sphere. technically worth approximately nothing though... :)</comment>


Entrepreneur State of Mind - <AUTHOR> http://www.youtube.com/watch?v=exmwSxv7XJI

<comment><USER2> Really well done and inspirational video. This is officially my new anthem.

</comment><comment><USER3> This is awesome! Sooo funny! Sooo true... So well done!</comment>


London Underground banned it, the banks will hate it, what do you think? - <AUTHOR> https://transferwise.com/blog/2013-10/the-money-transfer-revolution-goes-underground

<comment><USER2> Yeah, as a person regularly sending money outside UK I felt this pain.

Then, bitcoin appeared, thanks to which you can send money to many countries for free (or even with a small gain on exchange rate, if youre lucky).

</comment><comment><USER3> I really wish we could shine a bright light on _all_ the dodgy stuff banks do.

</comment><comment><USER4> > TfL tried to ban it

Why would TfL specifically get involved? It's more likely this is an issue for the ASA, on account of it appearing to use the word 'FUCK', which is hardly controversial.

<comment><USER5> Looks more like FYCK to me, and that is the same levenstein distance as FCUK which is everywhere.

<comment><USER4> Transposition vs substitution; I'd say F*CK is more likely to suffer the ASA's wrath than FCUK. But who knows, need more details to be sure of anything.

<comment><USER5> You would say transposition vs substitution but there a few different string metrics. I picked one of the most popular which treats substitution as the same as transposition.

[http://en.wikipedia.org/wiki/Levenshtein_distance](http://en.wikipedia.org/wiki/Levenshtein_distance)

It shouldn't be hard to argue and force them to disclose what string metric they are using and what distance is the minimum if you're prepared to take them to court.

</comment></comment></comment></comment><comment><USER6> I saw the ad. Kudos for getting onto the tube.

</comment><comment><USER7> Isn't that a bit controversial?

</comment><comment><USER8> How did this reach the front page of hacker news!? This is nothing more than an advert for sending money overseas. Oh and for the marketing team running this blatant advert, here's a free tip that will help your SEO a bit, add a 301 redirection on your non-www site. You don't even redirect [http://transferwise.com](http://transferwise.com) to [http://www.transferwise.com](http://www.transferwise.com)</comment>


Vim is hard, I just want to click around - <AUTHOR> http://jeffkreeftmeijer.com/2011/vim-is-hard-i-just-want-to-click-around/ <comment><USER2> I've always been a little puzzled by people who use a file-drawer or file-list or similar addon with Vim, and I now I think I know why: I'm guessing most of these people have Vim open as their One Tool, much like another programmer might have Xcode or Visual Studio open as their One Tool, and they want to get everything done in it.

At work, I usually have at least two windows open at all times: Vim full- screen on one monitor, a terminal full-screen on the other—or sometimes one terminal taking up most of the screen and another smaller terminal tailing a logfile. The Vim window gets used for editing (of course), the terminal is used for running test suites and exploring the codebase and finding and opening files in Vim. The reason I've never felt the need for a file-browser plugin in Vim is because I've always used Vim with an external file-browser. :)

If anyone's interested in opening files in an existing gvim window from the terminal, here's the script I use in Linux:

        gvim -f --remote-tab-silent "$@" &

(I believe MacVim comes with a similar 'mvim' script you can use on OS X) If you don't want files to open in tabs, change "remote-tab-silent" to "remote- silent". If you call the script and there's no existing gvim window, a new one will be created.

<comment><USER3> Unfortunately, the remote features require a GUI version of vim. Personally, I prefer to run vim in a tab of my terminal.

<comment><USER2> The remote features require a version of Vim with GUI features compiled in, but you don't have to _run_ vim in GUI mode to use them. The only difference is that when started in console mode, Vim won't register itself as a server unless it's explicitly told to use a particular server name:

        vim --servername FOO

If you start vim in another tab with the same servername, you can open files in the first Vim, no problem:

        vim --servername FOO --remote-tab ~/.bashrc

<comment><USER3> > The remote features require a version of Vim with GUI features compiled in, > but you don't have to run vim in GUI mode to use them.

You do have to have an X server available though; the client/server communication occurs via X.

</comment></comment></comment></comment><comment><USER4> I have a hard time watching people traditionally navigate filetrees and tabs

with emacs and ido-mode enabled I press Ctrl+X B to open a buffer, Ctrl+X F to open a file, I typically type 2 or 3 characters from the filename and emacs gives me a list of matches (with autocomplete), usually the first suggestion is correct and I press return to open the file.

I barely need to think while I do this, there is no visual clutter on my screen, and I can usually finish the before someone could take their hand from the keyboard to the mouse and move to the filetree

<comment><USER5> The (admittedly not as good) equivalent to ido-mode in vim is FuzzyFinder.

<comment><USER6> One of the biggest shortcomings of vim is the lack of a good ido-mode style file-opener. People seem to rave about command-t, although getting it set up on Windows proved too annoying for me.

FuzzyFinder is nice, but graphically it's a mess. Like everything else in vim, really.

<comment><USER7> This is the biggest meta-shortcoming of vim: the fact that it doesn't come with a built-in programming language. This forces extension authors to bring their own, with the expected consequences.

<comment><USER8> It has vimscript, but vimscript is at best emacs-lisp's inbred nephew who is just as old but huffs glue and has sex with chickens.

<comment><USER9> Actually, you can also use mzscheme, perl, python, ruby, and lua to script vim.

<comment><USER10> Indeed, but that's what the grandparent is saying—you need to bring your own language to the party.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Reposting this for horseshoes; it seems to have been mysteriously censored.

Getting familiar with GNU screen and within vim, liberal use of :tabnew foo got me to prefer a terminal emulator for working and notes over eclipse / gedit / nautilus. (gt and gT move to different tabs and :tabm N moves the current tab to tab N btw). If from within vim you :mksession bar.vim, vim saves all your open tabs so you can :wqall and open the tabs again from the shell with vim -S bar.vim

Like seemingly everyone, I organize projects into project/doc, project/src, project/data, project/bin etc. For example, I have a start.vim each in project/doc and project/src.

Then I put lines in ~/.screenrc

      chdir /home/horseshoes/workin/myproject/doc
      screen -t myproject_doc vim -S start.vim
      chdir /home/horseshoes/workin/myproject/src
      screen -t myproject_src vim -S start.vim
      screen -t bash bash

When I start screen it automatically opens one window containing a vim sesh with all my most-looked-at documentation tabs (so I can refer to wth I was thinking and organize my mental pushdown stack a little), one window containing a sesh for the source files I currently work on, and a third window holds a shell so I can look for and alter other files or start sqlite3 or make or w/e.

The point is it fires up work for me so I just have to open a terminal and type screen and it's instantly ready compared to opening eclipse or visual studio and then navigating to the relevant related notes and documents, or cluttering up the place with a billion (or even 2 or 3) terminal emulators, since screen multiplexes them. I also like to have screen windows open with cmus (music) and a python interpreter (my calculator and preferred random 'what to make for dinner' decision maker).

I also prefer the command-line environment for programming and also most general use because of the kool tools it's full of you are no doubt very acquainted with (ls, locate, grep, less, ps, pipes et al).

(End of mysteriously censored post.)

I have no idea why this might have been censored. Maybe it's the obnoxious use of "w/e" as an abbreviation for "whatever"?

<comment><USER12> horseshoes is hellbanned for this comment: <http://news.ycombinator.com/item?id=2928894>

This is why I browse with dead comments enabled. A single particularly poor comment is a rather inaccurate indicator of future comment quality.

<comment><USER13> Certainly some moderation is appropriate for that comment, but I think a permanent invisiban is a bit of an overreaction to that. Does this kind of thing happen frequently?

<comment><USER14> Yes, more so than you might think. Another showdead user.

</comment></comment></comment></comment><comment><USER15> A lot of people miss the issue of browsing through projects that you aren't familiar with. Auto-completing/fuzzy matching takes more time than actual browsing in such a case, because you're probably guessing half of the time. Maybe it's just me, but I find that to be annoying within a minute.

</comment><comment><USER16> VIM defender rushing in. I wrote a post which translates 100 Textmate features into VIM, and vice-versa. In particular, I included a section on getting used to the NERDTree.

<http://www.jackkinsella.ie/2011/09/05/textmate-to-vim.html>

</comment><comment><USER17> Command-T[1] solved this 'problem' for me very nicely.

[1]: <https://wincent.com/products/command-t>

<comment><USER18> I agree completely about Command-T. I don't use any type of file drawer at all, I tried NerdTree and found it really annoying. The way I see it, you either know where something is already, in which case Command-T does the job, or you don't, in which case you may as well use a console, or just use :edit . in vim to open up the file & folder browser to start browsing around.

Command-T forces you to think: where is this file? And then you type in a handful of characters and retrieve it immediately. To me, that is very vim- like, because it's similar to the editing experience, where you think: what is the most efficient way to do X?

</comment></comment><comment><USER19> Surprised PeepOpen hasn't been mentioned yet. I use it exclusively with MacVim on OSX. It is a bit unconventional but works amazingly well: <http://peepcode.com/products/peepopen>

<comment><USER20> PeepOpen is the main reason I use MacVim. So excellent.

<comment><USER21> I have struggled for a while to get PeepOpen and MacVim working together. I can run :PeepOpen, and it will switch to the running peepopen application, but it doesn't load up with the project files. I've tried all sorts of .vimrc config settings that the internet has to offer, but none worked.

What's in your config for it?

<comment><USER20> I actually don't have any .vimrc config for PeepOpen. :cd into your project directory and use the shortcut (I changed my shortcut to cmd+t).

In MacVim preferences, I set "Open files from applications" to "in the current window / and set the arglist"

</comment></comment></comment></comment><comment><USER22> I too wanted to click around the first month (+/-) after switching to vim, I think we all did.

However, it seems like the author learned the basics of vim, but stopped before he learned about powerful navigation keys, visual mode etc.

I think the moral is: if you feel you don't get the hang of vim/nerdtree etc., don't give up - keep going, there is a reason why so many people use it.

<comment><USER23> > don't give up

Yes. All the tutos I have read recently insist on using hjkl, which is a matter of taste, but do not emphasize what I believe is the most important (for terminal use): cut and paste.

\- Easy cut and paste in Vim is done with yy and p, avoid mouse and ctrl-c/v or any other trick that is not "inside" Vim.

\- Good trick are to first select a block with <shift-V>.

\- Don't forget P, which is pasting above current line or before cursor, often more logical than p.

\- This implies to open different files inside the same Vim instance, using :Explore or :edit

\- If you have to copy some outside text inside Vim, by all means, use the paste mode (:set paste), if you don't you'll mess up your text.

<comment><USER24> Also worth remembering is that _every command that deletes really cuts_. Which is to say, deletion commands like x and dd store the deleted content in the register that will be used when you hit p or P. This is important to know both because it can be _very_ useful sometimes and because it can get in your way other times (e.g., if you're trying to repeat an action and keep replacing a line with another line, you'll have to paste before you delete so you don't override your register).

<comment><USER25> Or you can specify the register name. Don't limit yourself to the unnamed register.

<comment><USER24> Absolutely. My fault for not mentioning it :)

</comment></comment></comment></comment></comment><comment><USER24> I've been playing around with vico for a couple of days (<http://vicoapp.com/>) and it seems pretty nifty in terms of solving some of these from-textmate-to-vim "problems". It uses TextMate bundles and supports them reasonably well as far as I can see. It also has Cmd-T and is very much a native app rather than a wrapper around a terminal app, which is more what MacVim tends to look like (it's what I've been using for the couple of years since I switched to Mac).

There are some holes in the vi commands that I use; some of them can be filled in (I'm working on some of the ones I'm missing), some of them will probably have to wait for official work, but either way I'll probably keep using it for a few days and see how things feel at the end.

</comment><comment><USER26> I'm working on a Gtk2 application that basically solves the same problem. It adds a sidebar with things like a file browser to a GVim editor. For getting a feel for a foreign codebase I find it much easier to use something like this than to switch between navigation/file view all the time.

I tried plugins like NERDTree, which are awesome in one way because they work everywhere vim works (like in the terminal). However, I didn't really like their feel in combination with GVim and tabs.

</comment><comment><USER27> I created a fork of janus that removes NERDTree from the distribution just for using it with alloy's fork. Also some other nice textmate behavior like quote/brace completion is included. So to get started immediately you can use it too, it is on github: <https://github.com/JFrolich/janus>

<comment><USER28> Thanks, giving this a shot now.

</comment></comment><comment><USER29> I still click around in MacVim sometimes (mostly for navigating deep NERDtree hierarchies and for selecting text within a line).

It's all about what's going to be fastest and take the least amount of mental context switching. I didn't choose vim because it's so hard to move to the mouse occasionally, I chose it because some things are much faster/easier than in TextMate, and for some things the mouse is still faster.

Sure, from a purist point of view it's terrible, but I think vim mastery has diminishing returns at some point (granted, it's a pretty far point up the learning curve).

</comment><comment><USER30> The author mentions trying to get around this with the nerdtree plugin. I stay away from heavy plugins like this because I think they compete with the minimalism that is so nice to the feel of vi. But I can see why you'd be attracted to it given the difficulty of dealing with multiple files.

I do this to get nice access to multiple files:

        set hidden         " allows files to be opened in background
        nmap <C-j> :bp<CR> " edit prev file with ctrl+j
        nmap <C-l> :bn<CR> " edit next file with ctrl+l

(goes in $HOME/.vimrc)

<comment><USER5> FuzzyFinder is the easiest file and buffer navigation plugin I've found. You should try it. Fuzzy matching is better than having to keep track of what files you have open and in what order.

<comment><USER31> :b completes on path.

I found FuzzyFinder slow and it interrupted my workflow.

<comment><USER5> It is slow when it has to first index your files, yeah. Path completion is not really comparable.

</comment></comment></comment></comment><comment><USER32> The times I open new file vs times :e line is already in my vim/bash history is tiny. And that tiny amount is handled fine by vim's filename completion.

There seems to be a big divide in usage between gui vim'ers who are probably doing one window/ide thing vs terminal vim'ers who probably have multiple terms/vim's open and use unix/cmd line as their die.

Note I make value judgment as to which is better (I'm sure people vary and so should their tools). My point is you should figure out which one you are and filter vim suggestions appropriately

</comment><comment><USER33> There is nothing wrong with being more productive with a tool like TextMate instead of vim, emacs or whatever IDE or editor. You should simply use a tool that works you.

</comment><comment><USER34> I don't get it. When I am working on a project I just go to the root project directory and open up vim. NERDTree automatically loads the file structure of the project directory which is my current focus. Why should I need a file- drawer with the unnecessary folders showing?

<comment><USER15> You don't "should" anything. If you don't feel the need, then don't install it.

<comment><USER34> A bit harsh response I think. Sorry I did not get my word right. But can you explain why it is useful to you?

<comment><USER15> My response wasn't meant as harsh, it just lacked a smiley ;)

I work on a lot of OSS projects and our company does consultancy. This means I browse other's projects on a daily basis (i.e. I don't know the filenames yet). That, combined with the fact that I have a deep love for GUI design and platform consistency, has made me come to the conclusion that something like NERDTree wasn't working for me. I tried to keep on going for a few more weeks, but in the end I decided that writing a file browser would cost me less time than I lost during these few weeks.

I'm glad I wrote it, because now I'm perfectly happy with my MacVim setup, which I wasn't before. I'm also very glad I did not decide to revert to using TextMate or any of the other new closed source editors.

To conclude, it's a bit of a feeling-thing. I'd invite you to try it out for a while to see if it works for or against your flow. No hard feelings either way :)

PS: It might not be apparent from the article, but the browser provides a few more functions that os x users might be used to in other apps. See the last screenshot: <https://github.com/alloy/macvim/wiki/Screenshots>.

<comment><USER35> I think I will give this a try. Thank you for writing this and taking the time to release it.

Browsing codebases that I am not familiar with is the exact use case for me. For navigating my own project, I do fine with MacVim + Terminal + "mvim in new tab in existing window conf" [1]. But for exploring an unfamiliar codebase, it's too cumbersome.

\---[1]---

      alias mvim="open -a MacVim.app"
      In MacVim Preferences set "Open files from applications" to:

        "in the current window"
              "with a tab for each file"

Then, in Terminal you can do, "mvim file.ext" to open file.ext in a new tab in the existing MacVim window (or new if no window).

</comment></comment></comment></comment></comment><comment><USER36> I find myself never straying very far from VIM. It keeps drawing me back. The registers, motion commands and fingers never having to leave the keyboard just work so well for me. Multiple tabs in iTerm keep me well organized and speedy.

</comment><comment><USER37> That's a very nicely designed blog. Kudos to whoever did it, Jeff.

</comment><comment><USER38> I've personally been thrilled with LustyExplorer

<http://www.vim.org/scripts/script.php?script_id=1890>

</comment><comment><USER39> I'd say most unfavourable opinions are tied to a lack of knowledge but having powerful features ultimately doesn't negate that it's uncomfortable for some.

</comment><comment><USER40> gVim is hard; I just want to type ctrl-v to enter blockwise Visual mode.

I normally use vim on the command line, but a lot of my coworkers use gVim on Windows. Whenever I try to help one of them out, I can't stand the fact that ctrl-v is remapped to paste by default. I recently found out how to make gVim sane again. In _vimrc, comment-out the following lines:

      behave mswin
      source $VIMRUNTIME/mswin.vim

<comment><USER41> On Windows, ctrl+q will get you the Visual Block selection.

EDIT: I think it also works on Linux... Sitting on my Windows box, at the moment, so I can't test it.

<comment><USER40> It does (both on Windows and Linux), but gVim still uses v and V for the other two Visual modes, rather than q and Q. It drives me nuts!

</comment></comment></comment><comment><USER42> I'd have probably liked this when I didn't get used to Window navigation on VIM, now I want everything to work with C-W C-[HJKL].

</comment><comment><USER43> To me the title reads "I just want to dick around", because ultimately, that's what you're doing.

<comment><USER44> yeah whole post is kind annoying, he wants to do it, but he will not, maybe he will, no he will not, like a girl. I didn't find vim that hard at all, just learn it and use it, that is all.</comment></comment>


Internet Entrepreneurship: How to Avoid Becoming a Stressed-Out Loner - <AUTHOR> http://www.gamasutra.com/blogs/MichaelGnade/20140107/208141/Internet_Entrepreneurship_How_to_Avoid_Becoming_a_Stressed_Out_Loner.php <comment><USER2> Am I the only one who spends 16 hours in front of a computer (mostly) working 6 days a week, managing staff exclusively through email and oDesk, and loves it? Maybe it's because I view the entrepreneurship stage as the filling between two sides of the cookie sandwich, with tons of partying, debauchery, and socialization in the years before I got into it, and tons of it on the other side once the damn thing's finally making enough money to hire a real management team to watch the stables for a while, while I go out and take a years-in-the-making vacation to end all vacations... then come back and get to work until I don't feel like working on business anymore.

I also don't use Facebook, Twitter, or anything else along those lines... if you want to reach me, you can email me, and I'll respond when I check email once every few days, or if you're one of the very few people who has access to my phone, you can call or text me and we can chat or grab dinner. No cyberstalking or hours lost to staring at social media inanity wondering why I'm not a part of all the pretend-excitement people portray themselves as engaging in for me. Wonder if this vicarious living through people's puffed up social lives on social media isn't a big part of why the author feels so left out.

<comment><USER3> _16 hours in front of a computer (mostly) working 6 days a week_

This is not sustainable no matter how much you love it. There is simply not enough time left to live healthy life - rest, exercise, be in a good relationship. Please do not do the same mistakes I made. I used to say what you say and I used to love my work. But I burned out. Love turned into hate. I had to quit - I just could not do it anymore. And I was left with severe depression, anxiety attacks, health problems and worst of all - loneliness. I did not have time for social life and now I have no love in my life, no sex, no intimacy, no meaning, nothing worth living for. I wasted few years of my youth that I will never get back and I just hope that somehow (with a lot of help from my therapist) I will be able to recover and enjoy life again... but it seems almost impossible now. I am in a really bad place right now... and I see you going there as well and loving it.

<comment><USER4> I completely agree. I'm just 23 and I burned out, last year I decided going on my own, freelancing and launching own products. That was a hard year, a lot of stress, anxiety attacks. I made a huge mistake. Hopefully I'll try to change this.

<comment><USER5> This thread hits home with me. Its been a year since I went all into building my product. Its taken some time since I'm a solo founder and I am willing to accept that. It sucks. Sometimes you start questioning what you're doing. I started getting sudden anxiety attacks late last year. Abnormally long work/coding hours take a toll on your health. My most recent anxiety attack lasted 3 hours. Anyway, if any of you are in the sf/bay and want to hang out talk about product or whatever, I think there's a lot we can relate to. There needs to be more positive encouragement in our community.

mk

</comment></comment></comment></comment><comment><USER6> Beautiful post. Abstract out the gaming aspect, and throw in a couple of kids, and I would've believed that I had written it. In my experience, it only gets harder once you start reproducing. All that kick ass time you have to decompress (hot Yoga, etc.), is now replaced with home stress (which is >= work stress) - and it only compounds everything.

I find that I increasingly crave human interaction (besides screaming children and agro SO), and really appreciate human connection more and more, when it does happen. But sometimes that human interaction comes at a cost of productivity and therein lies the rub.

My cutoff for work is supposed to be 11pm (shutdown all devices and decompress for at least 30min befor bed), but eventually things flare up - I'm up until 2am for a few weeks and forget all about my 'cutoff'. A few months later, I realize that I need a cutoff again. Vicious cycle.

Sorry, I'm rambling. I guess what I'm ultimately trying to say is that you are not alone - I think it's the price we pay, but it's always good to be smart about our approach.

</comment><comment><USER7> I'm 25 and live precariously off of the meager income from my own projects.

My goal is to grow my income so that I can "finally do what I want", but sometimes I wonder if I'm squandering my life in a delusion.

Recently, my safety-net project suffered a catastrophic collapse out of nowhere and now I'm quickly trying to rebuild it.

Over time, an increasing amount of my energy is spent warding off the specter of self-doubt.

<comment><USER8> I'm moving towards doing more of my own projects, but for the past two year's I've been quite happy with contracting three to five days a week. It's harder to work on your own stuff when you're working for someone else in an office for more than three days, but it's a good way to save up some money and it's nice for a change.

</comment></comment><comment><USER9> "The Struggle is when you wonder why you started the company in the first place.

[...]

The Struggle is not failure, but it causes failure. Especially if you are weak. Always if you are weak."

So untrue. You are not weak if you quit ! And conversely, you are not strong if you don't quit.

Sometimes, you should quit, and it takes courage to do so: when you gave so much to your project that quitting breaks your heart.

<comment><USER10> It was kind of funny to read the whole "Struggle" part. My response is, Nobody is forcing you to go through the struggle. Live in Bangladesh for $1/day and you will know Struggle. Whoever wrote it is seriously need to get some perspective.

<comment><USER8> And while the author is at it, he should stop complaining about anything because there is always someone worse off than him!

</comment></comment></comment><comment><USER11> No lonely, no focus. No focus, no productivity.

Programmers are a different creature from other people. But enjoy.

</comment><comment><USER12> This is something I've thought about a lot and I think a lot of the loneliness comes in the early stages of being an internet entrepreneur, the times when you don't need to / can't afford to hire full time employees and open an office. For me at least, my ideal working environment would be something like the way 37Signals is setup. When you get to the point where you can hire a handful of employees and open an office but only go to the office when you feel like it.

Another option that also sounds fun is to startup a small retail company, maybe related to one of your hobbies, something that at least requires some foot traffic at a physical location. Find someone to run it and go there to manage and check on things whenever you feel the need, or better yet, grab your laptop and work on your internet startup from there.

It seems that all my ideas require you to have some extra cash and time on the side though so they're not always possible for a 1 or 2 man bootstrapped startup. If you can get to the point where you've got things running pretty smoothly with your internet company and are making decent money, these options might be something to look forward to.

</comment><comment><USER13> > Few or no colleagues

> Working remotely is lonely

Both pros for me.

</comment><comment><USER14> We created tribes ([http://tribes.techendo.co/](http://tribes.techendo.co/)) to basically combat this while expanding your network and resources. If you're in SF, you should join us. If you're not in SF you can take our guidelines ([http://tribes.techendo.co/rules](http://tribes.techendo.co/rules)) and help create a tribe in your area.

</comment><comment><USER15> People with experience with this, what do you think of coworking spaces? They seem like a great solution to the loneliness and can even yield some nice networking. Any downsides to them?

<comment><USER16> They are loud. Then again I am a programmer, so headphones can solve the only real downside for me. I don't have to make calls all day.

But to more specifically address your offering a coworking space as a solution to meeting other people. It probably comes down to personality, but I am an introvert and find it very difficult to just start talking to someone. So, it ends up a bit like being at a party full of strangers. You are pretty sure there are some cool people around, but have no idea what the first step is for locating them and then breaking the ice. There are sometimes happy hour type events, but people tend to group up with people they already know and give you the 'what do you want' look if you start the slow awkward approach. Again, there are lots of people who are good at this, I am not one of them.

To summarize, it can be a good solution or not depending on your personality. My solution is to schedule lunches with my friends and people I have met who were interesting. That lowers the burden of meeting new people at the coworking space, which can then happen a little more organically.

<comment><USER17> What if it was a coworking space that first introduced the members, what they do and what their plans are, etc (as an ice breaker). Being able to gather many entrepreneurial minds in one building is quite powerful, many opportunities there...

<comment><USER18> Many coworking spaces have 'after work talks' or work with local meetup groups so they end up doing this kind of thing.

They are loud though - I worked in one once which was full of recruitment people who yakked on the phone all day, not nice.

</comment></comment></comment></comment><comment><USER19> Interesting. I also graduated with a degree in Real Estate at about the same time as you (bad timing) and have since moved on to the software industry (self-taught).

</comment><comment><USER20> Very beautiful put and aptly said. And, yes in the end, it's worth the reward.

</comment><comment><USER21> Too late, voice of wisdom, too late!

</comment><comment><USER22> another casualty here.

</comment><comment><USER23> does it bug anybody else that the alt text is in the stress level screenshot?</comment>


How America Kicked Me Out - <AUTHOR> https://medium.com/p/cb66b7d4077b

<comment><USER2> This story is terrible - I hope you find your way back to the Bay, Ben. Glad you were able to find a solid growth position for yourself.</comment>


Caffe2 adds 16 bit floating point training support on the NVIDIA Volta platform - <AUTHOR> https://caffe2.ai/blog/2017/05/10/caffe2-adds-FP16-training-support.html <comment><USER2> From first looks, there is little doubt that that NVIDIA's Volta architecture is a monster and will revolutionize the AI and HPC market. But the article seems to avoid quantifying how 16-point FP operations are beneficial against 32- or 64-bit FP operations in real-world usecases, or how the Caffe2 / NVIDIA architecture provides any significant boost to FP16 in particular, especially apropos to images (or why FP16 is better for image data in general).

I'm interested more in understanding why Caffe2 would outperform Theano, Tensorflow, MXNet, etc. once Volta chipsets are generally available, beyond early pre-release optimization, particularly when most of the front-runners are already leveraging / taking into account NCCL, CuDNN, NVLink, etc. When the burden of adding support for new NVIDIA primitives is so low, what gives Caffe2 an advantage beyond an ephemeral "we were partners with NVIDIA first" one-up that would last for a couple of months at most?

(Apologies in advance if this post sounds overly negative, but I am constantly evaluating the current crop of frameworks for the trade-offs they enforce on the problem space, and a definitive answer would be very helpful.)

<comment><USER3> Caffe2 seems to be engineered for efficiency as opposed to flexibility. For example, Caffe2 is apparently Facebook's go-to choice for mobile edge device deployment for applications such as style transfer.

<comment><USER4> Efficient how ? In terms of memory management ?

<comment><USER5> TPUs are smaller in terms of Si real estate and burn less power. Also, they can be made much faster.

</comment></comment></comment></comment><comment><USER6> The AnandTech article on the Volta has a lot more information on the new architecture: [http://www.anandtech.com/show/11367/nvidia-volta-unveiled- gv...](http://www.anandtech.com/show/11367/nvidia-volta-unveiled-gv100-gpu- and-tesla-v100-accelerator-announced)

It's interesting the speed up isn't more pronounced between Volta and Pascal considering the Tensor cores on paper give you about 6x the MFlops. The price differential looks large.

From AnandTech: "By the numbers, Tesla V100 is slated to provide 15 TFLOPS of FP32 performance, 30 TFLOPS FP16, 7.5 TFLOPS FP64, and a whopping 120 TFLOPS of dedicated Tensor operations. With a peak clockspeed of 1455MHz, this marks a 42% increase in theoretical FLOPS for the CUDA cores at all size. Whereas coming from Pascal, for Tensor operations the gains will be closer to 6-12x, depending on the operation precision."

</comment><comment><USER7> Are numbers available for FP16 on P100 or FP32 on V100? It would make for a more direct comparison.

EDIT: Nvidia's advertised TFLOPS are:

             FP16  FP32  FP64
        V100 30    15    8.5
        P100 21.2  10.6  5.3
        K40  4.29  4.29  1.43

<comment><USER8> Your table doesn't include the new "tensor core" TFLOPS of V100.

That's a core that does 4x4 FP16 matrix multiplication + 4x4 FP32 accumulation in one go.

That's where V100 gets its boost, up to 120 TFLOPS.

</comment></comment><comment><USER9> The GPU looks like a monster, and I am sure it'll deliver more power to AI applications, but what I really want to know is when I can put one in my gaming PC.

I think it's great that what started as a specialist gaming device is now being used in industry for Big Things. The development cost that Nvidia et al. have invested in new designs has undoubtedly been financed in (large) part by the gaming community. Now income and advancements for both sectors feed into the other and gamers like me are reaping the benefits with reduced price:performance across the range.

<comment><USER10> Meanwhile I still remember being seated at the Games Development Conference talk in 2009 where Intel tried to convince us how Larrabee would change the world of computing.

Still waiting for them to produce anything worthwhile buying instead of AMD and NVidia GPUs.

<comment><USER11> Actually, it's now called Xeon Phi: [https://en.wikipedia.org/wiki/Xeon_Phi](https://en.wikipedia.org/wiki/Xeon_Phi)

<comment><USER10> I know, they are pretty hard to get and as such largely ignored by HPC and gamming communities.

<comment><USER12> Hard to get? For better or worse TTBOMK there are more Intel Xeon Phi machines on the TOP500 than GPU accelerated systems.

<comment><USER10> Yes for people with normal bank accounts vs random computer store.

</comment></comment></comment></comment></comment></comment><comment><USER13> I'm a long time Nvidia user. However, the recent article headlines have been a word salad.

The new tesla volta super flip flop at 1.21 gigawatts blah blah blah.

Just saying.

Also Kudos to Nvidia for the buzzword/made up word creation for their products.

<comment><USER14> Surely getting people to refer to their vector lanes as "cores" was their biggest piece of marketing magic. Yes, they're more flexible than SIMD cores but not more so than an OoO core's execution ports.

</comment></comment><comment><USER4> I can see why they launched 1080 Ti early. Had I not seen this I'd definitely not be waiting for Volta.

How are things in the red camp ? There was some HIP thing where Fiji was as good as Pascal.

<comment><USER5> Any idea on the timeline for consumer Volta?

<comment><USER15> Early 2018 depending on GDDR6 supply. Seems like Hynix will start mass production on in late 2017.

</comment></comment></comment><comment><USER16> I understand the pedigree of these cards, but at what point do we stop calling them GPUs and start calling them something else? MPU? TPU? I don't know, but isn't it a little bit weird to keep using the word "graphics" for something that is being made more and more specifically for other things?

<comment><USER17> I don't see the point of adding to the confusion. They've been called GPUs for ever, everybody agrees on the term, why not continue to use it?

<comment><USER18> I like the term "GPGPU" (General-Purpose Graphics Processing Unit) as it's at least explicit about its general-usefulness.

<comment><USER19> It's the exact opposite of general purpose though, it's several specific purposes.

<comment><USER20> No, it's several specific purposes that heavily use the provided _general_ primitives. There's nothing stopping more things from using it, which makes it general.

You don't call your PC a specific purpose computer just because all you do is use google chrome.

</comment></comment></comment></comment></comment><comment><USER21> Can the Volta architecture be used to run WebGL in a Browser?

</comment><comment><USER22> cudnn 7?</comment>


What is Linked Data? ...featuring Yuri the unicorn - <AUTHOR> http://learnlinkeddata.com/articles/what-is-linked-data

<comment><USER2> I did an IAP on LinkedData at MIT and one of the session's was given by Sir Tim Berners Lee, creator of Internet and now creator of Semantic Web.

LinkedData has amazing power and capability,the only challenge is adopting it. NYTIMES has all its articles on Linkeddata, DBPedia is an RDF version of Wikipedia.

On the other side all the companies are opening their API's, linked data has a similar vision of data mashups. These two overlaps in few aspects.

[http://www.ted.com/talks/tim_berners_lee_on_the_next_web.htm...](http://www.ted.com/talks/tim_berners_lee_on_the_next_web.html)

</comment><comment><USER3> Can someone tell me how this isn't a doomed effort to impose a universal ontology on the web?

<http://en.wikipedia.org/wiki/Ontology_(information_science)>

Such an effort is doomed because in the actual "real world", there isn't agreement on what exact "real world objects" exist and so we can't simply create a single hierarchy of the world's data akin to the Dewy-Decimal system for organizing books.

"Yuri the unicorn" is actually a good example. If such a unicorn "exists", he is likely a character in cartoon or comic book. If he's popular, information about him might meaningful and important. Who provides it? The copyright holder? Wikipedia? Whoever registers the URL first? (and don't even start on the question of "does he really exist?")

The web has struggled-with and provided a half-way solution to these problems with the combination search-engine and leaving the decision up to the user. But an effort to create a single authoritative hierarchy of "real world things" will fail and what's a "link to a real-world thing" if it's not authoritative aside from a needless layer of indirection?

Edit: The web's "half-way solution" is actually really good and amazing all considered and the "semantic" efforts to go "forward" from this in many ways seem to be steps backward.

</comment><comment><USER4> I wish some major player (e.g. Google) started backing linked data. It would speed up adoption tremendously.</comment>


Stop Piping Cats - <AUTHOR> http://www.ibm.com/developerworks/aix/library/au-badunixhabits.html?ca=lnxw01GoodUnixHabits <comment><USER2> This is my least-favorite Internet meme. People "pipe cats" because they want the entire pipeline to read left-to-right, like:

       cat file | xargs foo | grep bar | sort | wc -l

It just _looks nicer_ than:

       < file xargs foo | grep bar ...

<comment><USER3> Speak for yourself, and I don't know anyone that puts the input redirection first. I do this:

      (xargs foo | grep bar | sort | wc -l) < file

It makes the pipeline one command, both lexically (verb comes first) and concretely (the pipeline is kicked off in a subshell)

<comment><USER4> But does the time it takes to launch the subshell equal the amount of time it takes to launch cat? If so your improvement is a NOOP.

<comment><USER3> fork + 3x(fork+exec) is going to be cheaper than 4x(fork+exec), especially if _cat_ isn't resident.

The point is a logical improvement anyway (not burying the input argument near the beginning). I'm kind of surprised that the bash folks haven't turned _cat_ into a builtin like they did with _time_ and some of the other coreutils.

It's too bad it's about 30 years too late to stem the tide of shit like _cat -v_ : <http://harmful.cat-v.org/cat-v/>

<comment><USER4> By the reasoning in your link, your suggestion of bash making 'cat' one of the built-in commands is the "cancer that's bloating UNIX."

<comment><USER3> The shell has always been the kitchen sink full of glue holding the whole thing together. There have always been builtins: language control structures, job control, etc. -- there are some things you can't trust others not to fuck up, and where the coupling would just get ridiculous.

Here's cat as a pure sh builtin:

      shcat {
        for arg in "$@"; do
          exec 3<>"$arg"
          while read line <&3; do
            echo "$line"
          done
          exec 3>&-
        done
      }

The shell by it's very nature can't just do exactly one task well, it's a programmable environment for living in. The _cancer that's bloating UNIX_ was the way that the BSD and especially the GNU crews took simple tools and cross- pollinated them randomly with stupid shit. Try running "/bin/true --help" on a GNU system sometime -- there's a damn good reason why "your shell may have its own version of true".

<comment><USER4>
      % /bin/true --help
      Usage: /bin/true [ignored command line arguments]
        or:  /bin/true OPTION
      Exit with a status code indicating success.

            --help     display this help and exit
            --version  output version information and exit

      NOTE: your shell may have its own version of true, which usually supersedes
      the version described here.  Please refer to your shell's documentation
      for details about the options it supports.

      Report bugs to <firstname.lastname@example.com>.

I wouldn't necessarily call that 'bloated' unless you feel that any program that uses one bit more than _absolutely_ necessary should be scrapped as 'bloated beyond belief.'

> _there's a damn good reason why "your shell may have its own version of > true"._

Because why exactly?

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I use cat because often I wind up doing a number of different commands on the same file. It's a lot easier to edit the end of the line, especially if you're just adding another filter, than to go back and modify the beginning.

eg

         cat file | less
         cat file | grep thing
         cat file | grep otherthing
         cat file | grep otherthing | cut stuff

instead of

         less file
         grep thing file
         grep otherthing file
         grep otherthing file | cut stuff

<comment><USER6> Sounds like you might want to learn about !$ (last token of previous command).

<comment><USER5> Yeah that's interesting, but the second version is still more complicated to assemble and takes more keystrokes, assuming up arrow gives the entire previous command.

<comment><USER6> Let's count for your example. In all cases, I'll exclude the actual name of the file. We type in the first command:

         cat file | less
         less file

The second version is 5 fewer keystrokes. On to the next command:

         cat file | grep thing
         grep thing !$

The second example is the same or fewer keystrokes. In both cases, you have to type "grep thing". In the first, you have to press the up arrow and backspace over "less" (at least three keystrokes), and in the second, you have to type an extra " !$".

I'll skip moving to "cat file | grep otherthing" or "grep otherthing !$", and consider the change to get to

         cat file | grep otherthing | cut stuff
         grep otherthing file | cut stuff

In both cases, you have to type " | cut stuff". If you key in the second example as "!! | cut stuff", that's an extra two keystrokes. If you key in the first as up arrow + "| cut stuff", that's only 1 extra keystroke.

In total, my version saves keypresses in the specific example and doesn't seem much worse in general.

</comment></comment></comment></comment><comment><USER7> The most useful thing I took away from this was not 'piping cats' but instead the interesting syntax for creating multiple directories in one go:

      ~ $ mkdir -p tmp/a/b/c
      ~ $ mkdir -p project/{lib/ext,bin,src,doc/{html,info,pdf},demo/stat/a}

<comment><USER8> It should be pointed out, since the article does not, that that is merely one example of shell expansion that can be used anywhere. It is not a mkdir feature.

        $ echo project/{lib/ext,bin,src,doc/{html,info,pdf},demo/stat/a}
        project/lib/ext project/bin project/src project/doc/html
        project/doc/info project/doc/pdf project/demo/stat/a

(I added a linefeed to prevent wrapping.)

<comment><USER9> My favourite use is when installing packages using package managers, especially when I need the dev packages.

Old fink example:

       sudo fink install lib{png,jpeg,ssl,whatever}{,-{dev,shlibs}}

which expands to:

       sudo fink install libpng libpng-dev libpng-shlibs libjpeg libjpeg-dev libjpeg-shlibs libssl libssl-dev libssl-shlibs libwhatever libwhatever-dev libwhatever-shlibs

<comment><USER2> Brilliant.

I am ashamed to admit that I usually say "apt-get install libfoo.*", wait for the downloads to start, hit Control-c, and then cut-n-paste the package names I actually want onto the command-line.

It sounds bad when I type it out, but it's really not the most horrible thing ever. But your way is definitely like 83x better.

<comment><USER10> If you don't know the exact package names, Ubuntu happily auto-completes apt- get and aptitude on package names. So I would just type "aptitude install libfoo" and hit tab a couple of times to see what libfoos can I install.

<comment><USER11> Or `M-*` to expand all the completions and then, if necessary, delete the ones you didn't want. Beats typing the extensions.

<comment><USER10> This is golden, I didn't know that.

A perfect example of the infinite features that can be found in bash manual page. I've been using bash since the early 90's and I've written lots of non- trivial programs in bash, and I know a lot many other people don't know and yet I had somehow managed to miss this pearl.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> That 0.005 seconds I saved by not piping cat will significantly increase my productivity! No more wasting time!

</comment><comment><USER8> Oh come on, you can't mention that without mentioning the Useless Use of Cat Award: <http://partmaps.org/era/unix/award.html>

</comment><comment><USER13> Great practical advice. I still pipe cats though because it's just more intuitive to me for setting up complex pipes.

<comment><USER14> especially if your using a test file instead of the program you might eventually use

</comment></comment><comment><USER15> You also can't follow a file with grep, but you can with tail. Doing so requires the grep option "--line-buffered", which sacrifices some performance, but not much compared to actually viewing the log data.

      tail -f access.log | grep --line-buffered "GET /blog/post "

<comment><USER16> I do this a lot, and I've never used "--line-buffered", nor apparently needed it. Google shows me a lot of people using that as a solution to a problem (not getting results immediately) I've never seen. Weird.

<comment><USER17> It's more likely if you have grep and several other operations piped together - the normal buffering leads to grep only printing every time it gets a full block of data, typically several lines.

</comment></comment></comment><comment><USER18> Why? The extra 3 letters of "cat" are usually going to take less time to type the mental overhead of "where do I put the input file for this command" or the additional pipeline reasoning. I actually sometimes do it one way and sometimes the other, whatever comes to my fingers first (which is going to vary according to how I'm visualizing the pipeline of tasks in my head).

In general I far prefer the (it seems to me) more Unixy way of having lots of very simple commands and chaining them together over the use of extra options and arguments.

</comment><comment><USER19> There is some really great info on that site. I'm a sys admin of 3 years and to see the comparison in performance is going to force me to change my scripting habits.

<comment><USER20> Really? You're changing your scripting habits based on gaining milliseconds?

<comment><USER19> You have to define usage here. They are giving an example of a single piped command on a file of who knows what size, probably not very big, hence milliseconds. However when it comes down to scripting large log processing, backups, and other forms of automation then I think it will yield better performance. Not to mention good coding practices, I am looking to improve in any form, something like this changes the way you think which will prove to be very useful when programming in ruby, c, java, etc. Not necessarily the use of piping commands, but just about how to be more efficient and less wasteful.

</comment></comment></comment><comment><USER21> <http://everything2.com/title/I+am+forced+to+smoke+my+cat> \- sorry!</comment>