I wrote a lengthy question and signed up but at the payment screen it required a credit card. I would have preferred a third party service like PayPal. I am not inclined to enter my credit card information into random websites. I would have been happy to donate the $20 otherwise.
I worked on the Ask Toolbar back in 2009. I did an AMA about it on reddit way back when[1]. I was hired to work on Bloglines, a Google Reader competitor that was shut down and I moved to the toolbar to work on the Firefox version.
I just wanted to make a good toolbar that people liked using. I worked on a Facebook version of the toolbar. A lot of the ugly things about the toolbar, the way it gets installed and what it changes for users are options the company (Nero, Oracle etc) that adopts the toolbar pick. It was a really good team with great people, but despite this I didn't feel good about working on the toolbar because of how it was used. Everyone on my team just wanted to make a really good toolbar. I am not proud of the work but not because of anything our team did. I don't plan to do any kind of work like that again.
API issues aside, I recently deleted my LinkedIn account and my life has been better off for it. My recruiter spam volume dropped from daily emails to maybe two or three times a month. I'm not sure if LinkedIn provides any value, I've never gotten a job that way.
I think stalking people on social networks is also a net negative experience. I realized I should spend less time worrying about what other people are doing with their lives and focus more on my own.
There was also a recent NY Times article about how employers use LinkedIn candidates contacts to disqualify them for employment[1]. So LinkedIn can actually be detrimental to your career.
I just don't think LinkedIn adds anything. Businesses and recruiters use it to get your email to target you for spam. But what do you get out of it and think, if there wasn't a LinkedIn would you be out of a job right now?
Agreed with all of your points, but I'd like to add that your employment history is very personal and can quite often be used against you in ways you wouldn't imagine ahead of time.
Just like any personal information, its best to keep it as private as possible and default to a "need to know" basis. The era of naively optimistic voluntary sharing of sensitive personal information ended when we saw the potential consequences.
Potential employers want to know where you worked? They can ask you themselves. I'd also like to know who the board members are playing golf with, what their future capitalization plans are and if/when they plan on jumping ship. Too bad none of that will ever be shared with me. So why should I share intimate details of my past?
Information asymmetry is power in the modern world. It is foolish to relinquish it voluntarily.
I am one of those programmers who doesn't have a computer science background. Instead I have an MLS (and an undergrad anthropology degree) and thus though myself am not a librarian have some idea of the value librarians provide.
For one thing librarians try to satisfy the information need of a patron. This is different than answering the question asked, which even now search engines can't really do well yet. Google search is powerful but you're searching an unfathomably large index and your query is a key. What librarians do is try to understand the exact thing you want to know, which you may not even know when you asked the question. Often a librarian will respond to a question with a question.
A librarian will also continue to help until the problem has been solved for the patron. They'll encourage a patron who might feel discouraged. Librarians treat people as people, not as queries.
Librarians are also staunch defenders of privacy and information freedom. In America, librarians are professionals with a code of ethics, which is codified by the American Library Association. Librarians are taught the complex issues involving privacy, the chill effect. Librarians are not in the business of collecting your personal information or selling you advertising. Librarians fight censorship, and they fight to protect your privacy.
Librarians are supremely excellent at curating. Go to a Barnes & Nobles and look at the selection of children's books. Read some of them. Then go to your local library's children's section and read some of those books. It's night and day. Libraries are filled with amazingly valuable books that, especially in the case of children's books, address important issues, are beautiful and beautifully written. They're not stories about Barbie rescuing a fashion show, they're about relatable and enjoyable characters that discover the world around them, learning to understand themselves.
Having said all this there are considerable problems in the American librarian profession which turned me off to it.
Librarians were slow to react to digital content, which put them at a disadvantage on digital rights management issues. Walking into a public library can for some be like a time warp to 20 years ago, with volumes of books filling shelves everywhere. There's a reason for that, books can be lent out. By sticking to books librarians haven't been the force they should have been in fighting DRM and copyright laws that would enable access to digital information to more people. Libraries spend considerable amounts of money for highly protected digital content like JSTOR.
Librarianship as a profession is also one dominated by time in service type of seniority. I wanted to be a programmer at a library. I was a programmer at a library as an undergraduate student and there were librarians who programmed to manage the library's website and library. But coming out of MLS the unfortunate reality was that programming jobs are jobs that go to librarians with seniority. I would have had to man a reference desk for a decade. And that kind of advancement, where it isn't skill, but time spent warming a seat that gives you political power is just not for me.
Finally, it's not clear what the future of libraries will be. Fewer and fewer people are reading books. Libraries are very popular places, especially for children, but in many cases libraries are just places that have a computer or a meeting room. Public librarians don't seem to have an answer for what's to come.
I'm also a programmer with an ML(I)S, and while I do work in a library, I tend to share your negative analysis of the 'industry' and it's future.
But I'm curious what year you had trouble finding a job due to seniority things. In my experience from the late 2000's to now, programming jobs in libraries are not very hard to get for interested and qualified people. If you can make a good impression, are a programmer, and actually have an interest in working in libraries (with or without an MLS), and are willing to move (there are only so many jobs and might not be one in your city), I think you could find a job in a library. (University more than public; public libraries still don't really put much resources into in-house development, which is sad, I think).
Whether you'd want to or not is another question. The pay probably won't be competitive with the private sector, and, as you know, the work environment may or may not be entirely dysfucntional.
I love the idea of libraries. I don't think actual present day U.S. libraries are succeeding at achieving their potential in a post internet world. Before the internet, libraries and librarians were pretty much the experts at 'information retrieval', and I love the idea of "civil society" non-profit agencies that are experts at collecting, finding, and preserving information -- something society could use now more than ever. I don't see actual libraries meeting the challenge though, sadly. Perhaps it's unfair to expect to them to.
> The author critically misunderstands the way that `this` gets set...
I don't actually. (I'm the author) I know that the this key word is executed at run time to figure out what this is. It is true there are simpler ways to explain this and this blog post isn't that. I link to such a post at the bottom of my own. These are just some examples. There's also more to that blog post than what everyone is discussing, like returning from a constructor and global this in node.js and accessing this in eval and more. Anyway, I didn't submit this to HN and hadn't intended to. I also didn't intend to sit here tonight and put on a thick skin to deal with all this criticism for something I wrote months ago.
Don't take the criticism too hard. I enjoyed the post. I don't regularly write JavaScript so I found many points helpful. There is potential for pedantry here on HN, so dont take offense. I appreciate the post...
The article was a nice refresher about 'this' subtleties, but it put too much work into contrasting it against Java's this, instead of just laying out the actual JS rules.
To me, 'this' is JS is a lot more self explanatory than this is Java. And your article doesn't make that apparent. In JS this is just another object, like any other object. It follows the exact same scoping rules as every other object.
And the tragic thing about "this" being a magic keyword that looks up a dynamic value in the runtime, instead of a normal lexically scoped variable like it appears, is that 90% of the time "this" is exactly the thing you want a closure to close over, so you have to do ridiculous stuff like "var self = this;".
Even knowing this rule very well and being totally hard core OCO (Obsessive Compulsive ORDER, not Disorder) about the code, I still make "this" mistake ALL THE TIME, so whenever something weird happens, "this" mistakes are the first thing I look for.
"this" is such a terrible design flaw, it bites me even when I'm expecting it.
Patterns which could have been just as easily implemented using another more explicit technique for dynamic binding (like simply passing the dynamic parameter to the function as a normal argument) without fucking up the entire language design with invisible implicit magic, and dooming millions of programmers to repeatedly make difficult to detect, subtle mistakes, bugs and security holes.
Please give me one example of using "this" outside of lexical context, that is impossible or tangibly inconvenient to do by some other technique that JavaScript already supports.
Well, you could pass around the object but then you'd have to come up with a new object-literal syntax because `this` won't exist any more, unless you're planning on keeping it around but keeping it lexically scoped, in which case you have to stop using object literals as traits and prototypes.
At that point you might as well just redesign the language from scratch, which maybe you'd appreciate.
I agree. The fact that you have to write library code defensively to still work depending on how your method's call, or that you have to use an awkward bind to preserve the `this` context of a method is so annoying and error-prone to me.
Even when you remember to perform the awkward bind / Function.prototype.call / Function.prototype.apply / var self = this; you still may already be inside of another context where this is not correctly defined. So then your code LOOKS even more like it will work thanks to the cargo cult magic ceremonies you've performed perfectly, but in the wrong place. It's like going into the bathroom like you're supposed to, but then taking a shit on the floor right next to the toilet, then flushing.
You don't have to do that, you can tell a function what to use by using 'call' or 'apply'. Some people even use bind, but I think it adds too much line noise.
You don't have to do what? Make mistakes? Of course I don't have to make mistakes, but I do all the time, and so do other people.
You have to REMEMBER that you need to explicitly and inconveniently tell the function which "this" to use, by drilling down into Function.prototype.call/apply, even though it LOOKS like it will simply work like any other variable, which it doesn't.
Please consider that programmers are not perfect, and do not have infinite time or unlimited memory or perfectly focused and undistracted attention, and programming languages are user interfaces for imperfect humans, that should minimize the likelihood of errors, not set traps for less experienced programmers to make obvious mistakes, just so that more experienced programmers can gloat over how much smarter they are for having memorized every detail of the language spec. (-; I'm looking at you, automatically inserted semicolon! ;-)
And my point is that I AM an experienced programmer who has memorized every detail of the JavaScript language spec and uses it all the time, yet I STILL make "this" mistakes AGAIN and AGAIN. While on the other hand, I don't think I've ever made a "self" mistake with Python.
The way I think about it ('this' being like any other object), closures are just supplied a default 'this' object (window, in the case of web), and instead of providing a this argument via the argument list, you can choose it with the apply/call/bind functions.
I like your article and it fits well with my usual methodology of grokking something, namely running a bunch of tiny examples until I see the patterns.
Regarding the bit about Floobits, it's very nice of them to mention us, we love Neovim, and all of the things said are true, but the Neovim remote plugin API recently changed and we're rushing to get our plugin to be compatible. They were nice enough to let us know in our own issue tracker so we're nearly there. Our current plugin only works with versions of Neovim prior to the remote plugin change from before last week. Note this is the new remote plugin system, not the regular python plugins that have not changed and so vim plugins have no issues.
> My experience with NeoVim is that it's not ready to replace Vim yet
And when did you last try Neovim? Because I use it everyday with all of my plugins from vim with 0 problems. The new remote plugin system with python support is making huge strides. People have already started on Go support and I imagine JavaScript, lua, etc is not far behind. It's a very exciting time. I recently even got a commit merged, it's a great community and I've plastered my Macbook with Neovim stickers. :P
>Think i'll spend some time this holiday setting it up, appreciated!
That's not needed. With the default config or a simple vimrc it's a drop-in replacement. Some extensions don't work yet (even Syntastic) but that should be resolved soon.
That was months ago actually. I just retried and it works perfectly, but it's still synchronous and blocks the UI. This is what I expect from neovim: provide me with async lint/checks.
Not necessarily. The original patch Tarruda tried to get merged into Vim provided asynchronous commands in pure Vimscript (through a new kind of event for autocmd).
Do keep in mind that my experience is really limited: I compiled neovim and it works fine with my .vimrc & all extensions. So there's no reason to start fresh.
The problem with this is, unless you are a plugin author these things aren't compelling reasons to switch. Maybe they'll enable new types of plugins not possible before, but until that happens I don't feel a reason to use neovim.
> For the past eight months I have only seen Neovim folks being very professional, open, and quick to respond to user input.
They've done even more than that. They have gone to great lengths to be helpful. For example, tarruda created an issue on our own issue tracker to let us know they updated their python plugin architecture so that we could fix our Neovim plugin. He didn't have to do this.
tarruda has shown himself to be a very productive engineer and a great steward of a growing Neovim community.
Our experience with Neovim and Vim has been night and day. The reality is that with Neovim you can build plugins that do more than you can with vim, painlessly. I don't really want it to be a vim versus neovim thing, but Bram strikes me as someone who at the very least doesn't understand Neovim's goals. I certainly hope that Neovim's changes are not backported into vim, Neovim is much more open about contributions whereas with vim there's a single gatekeeper with limited time to address big changes.
As someone who has worked Neovim and written Neovim plugins, can you comment on how ready it is for "production" use? Could I switch over to it from Vim now, while using all my old Vimscript plugins? Could I right now use it and write plugins that do work on a separate thread from Vim? Is the msgpack API ready and/or documented? etc.
Before we get another rage post[1] I would like to emphasize that using Neovim requires that you keep up with the changes.
I use it full-time on supported platforms (everything except Windows), but breaking changes will require occasional reconfiguration, recompilation, or remorse.
I'd add to that to try and start using neovim. I've switched to it on Mac without a hitch and we (Floobits) have already moved our vim plugin to use the new neovim python-client plugin for much better async behavior. Making an async plugin for NeoVim is pretty trivial, here's a clock in your status bar:
Note this requires +python, :he nvim-python for how to get that (involves pip install neovim)
You can't do something like this clock in vim without the feed keys cursorhold hack that breaks using leader keys. Otherwise I'm still using vundle and have made 0 changes in my .vimrc other than move it all to .nvim and .nvimrc. All my plugins and vundle worked out of the box.
I had put neovim out of mind and settled for emacs/evil, but seeing an actual use case for the new plugin system makes me hopeful for it's fast growth and adoption.
Remember that floobits are the people that threw a tantrum when upstream vim wouldn't accept their patches, and have a vested ego interest in pushing a vim fork.
Eh... unless there's more to the story that I'm missing out on, I don't think it's fair to say they "threw a tantrum".
Basically, that company has a service that lets developers do real-time collaboration. Like working on a Google Docs document... except that it's for code, and collaborators can all use whatever supported editors they like. When they went to add support for Vim, they ran into problems with the "real-time collaboration" part... because Vim is single-threaded and doesn't have a non-blocking event loop:
The Vim maintainers kept rejecting it, for different reasons each time. After two months of back-and-forth, the Floobits guys asked the Vim guys to either give a comprehensive list of things in the patch that need to be different... or else acknowledge that they simply don't want the event loop thingy merged at all, and that Floobits should move forward with their own fork of Vim instead:
Personally, I don't have an opinion one way or the other on the merits of that patch. However, I think the Floobits guys were justified in feeling frustrated about the Vim guys dragging their feet and not being completely forthcoming.
Either way, if you do some quick web searching, you'll notice that Floobits became pretty big fans and online promoters of NeoVim from that time forward! So much so that you kinda have to take it with a grain of salt.
I'm not exactly sure what to even think about NeoVim. They've been plugging away for over a year, their GitHub repo has over a hundred contributors and two-thousand commits, and yet it's still pre-alpha? Also, the primary purpose seems to be allowing people to write Vim plugins in any programming language. However, it's not like the Vim ecosystem is hurting for plugins today. Besides, the whole point of "vimscript" is that it's self-contained and baked-in as part of the editor. Totally cross-platform, and always there. If I install a NeoVim plugin, then I have to make sure I have the right version of Ruby or Python or whatever on my box to support it? Yuck, no thanks.
As near as I can tell, any real value-prop for NeoVim is using it as an embeddable component. Like the Cloud9 guys' cloud-based Ace editor (http://ace.c9.io), or as something that IDE makers could bake into their desktop IDE apps. I don't really see what's compelling about it head-to-head with standard Vim, assuming it ever fully ships.
You're the one whose bad patches were rejected, you just dug through a year's worth of my comment history, and you're constantly and heavily promoting a terrible-design-and-still-no-beta-even-after-a-year-and-a-lot-of-donated-money fork of someone else's open source project ...
Neovim will have Lua (and LuaJIT) baked-in too, so Lua will always be there.
In my opinion initially there might be many different languages used by developers as they try out the new versatile plugin infrastructure. But after a while only a few languages should emerge as the dominant ones, because developers have the desire to help as many people as they can by making their plugins easy to be deployed and configured. I would guess Vimscript and Lua(both baked in), Python(nowadays it's practically ubiquitous) are the more popular choices. Personally I like Go (fast, easy concurrency, and single executable deployment).
Imagine that one day you want to use 10 plugins and have to setup all 10 language environments to use those plugins, and you have to set the whole thing on Windows...
You make a good point, and maybe nvim's decision to open up plugin languages will come back to bite it in the ass. It is a form of fragmentation in a sense, but I'm hoping the benefits will outweigh the drawbacks.
Does vanilla neovim offer anything that a vanilla vim user might like? I imagine I will make the switch at some point, I just wonder if there's any compelling reason to do so sooner rather than later.
It's pretty much still the same experience. Once plugins that take advantage of the async and when gui's take advantage of the API I'm pretty sure neovim will not just be equal, but far superior.
https://github.com/Floobits/floobits-vim
https://github.com/Floobits/floobits-neovim
https://floobits.com/help/plugins/nvim