The service is more general than that. From the pitch above you'll note that it intends to allow people to ask specific questions about a location, not just to signal where you might like to go to spend a night. In this case, the more people that use it, the more likely it is that your question will be answered and that it will be accurate and timely.
"Closures in particular are a very powerful tool in async/multi-threaded environments, but in the stateless/sync environment of a web application environment, they collapse down to syntactical sugar, and solve nothing that cannot be solved in other ways."
Closures allow for abstractions that are impossible to achieve without them. Yes, you can always get the same functionality, but you will be forced to deal with a weaker abstraction.
On second look I have to concede that I could be under-rating their authority. To be fair major investors will often sit on boards, but there's no need for me to make further conjecture.
You should be careful in thinking that you have to choose. In fact, regardless of what you do with .NET, I think it's a good idea to learn about the *nix environment and some languages that you're not yet comfortable developing in.
In my program at school I see a ton of students leaving university knowing nothing but one to three statically typed OO languages, and assuming that those paint an accurate picture of the full range of programming languages.
I'm not saying this is you, but if you're not comfortable outside of C#, Java, C/C++ etc. you're limiting yourself. Programming languages may be difficult to master, but you can glean a surprising number of lessons from one language by spending a few weeks with it. I think a few languages a year isn't asking for too much, and whether you use them or not, the lessons will transfer to the language you spend most of your time in.
If all of your programming experience involves using IDEs, do yourself a favor and spend extensive time in a powerful text editor like vim or emacs. While these editors might not have the advanced features present in IDEs, making the trade in favor of a more powerful programming language used in concert with a less powerful editor may actually make you more effective. The point is that you can't discern between the two until you've spent ample time in both. Being uncomfortable outside of an IDE can be a serious crutch as it keeps you using languages that the IDE can take full advantage of, and this excludes a number of languages that you should expose yourself to.
Nosql is an orthogonal issue. While relational databases are unlikely to ever go away, if nosql databases continue seeing success, there's no reason to think that seasoned .NET folks won't also make use of them.
Thanks for the heads up. That is quite convenient, unfortunately I'm now using vimium. I'm reminded that in my vimperator days gmail wasn't a problem because the vi key bindings just worked everywhere. All this is moot considering I can just patch the plugins. I assume vimium either has a similar capability or that it can easily be added, but it does allow a web app to trap key strokes before by default (opposite of vimperator)
I should have mentioned that another thing that can get you more intimate with vim keyboard shortcuts is trying out one of the vim browser plugins. I use vimium on chrome and vimperator on FF. These give you a number of the keys you're used to using in vim like gg, G, and even / search.
Gmail binds those keys, but I'm so used to scrolling up and down with j/k that the action Google chose is infuriating. What's worse is that turning the keyboard shortcut option off in gmail still captures the key press event, but silences it, effectively breaking my favorite plugin.
I'm curious, do you keep this around to this day? I never thought to do this when I started, but it might have been a good idea.
In similar vein I would say: If your fingers aren't constantly resting on home row, there's a problem.
Another advantage learning to use hjkl is that those keys are common in other unix programs, like less for example (which also has gg, G, / and some others)
Two very general suggestions, pretty obvious, but hopefully of some help.
1. The really obvious: You find yourself wanting to do something that is taking too many keystrokes. Think about what you're doing and how it could be improved. It might mean mapping a key to a series of commands or dreaming up a plugin you could write. When you do the latter, look around for one that is solving a similar problem; even if it doesn't directly solve your original problem it might be useful. I find myself trying out people's plugins, and often times they don't turn out to be useful and get deleted.
2. Something that is already in my workflow amazes me in its efficiency. Think about what makes this really cool and useful, and you might be able to think about how this technique can either apply to other situations.
There are some “breakthrough” improvements that I've had, so I'll share the ones I can think of.
- f and F for hitting some character on a line. I still use h, l, b, B, w, W, e, E and the others, but f/F is what I usually think to do. t/T also comes to mind of course, and these are especially powerful in concert with others, for example I use combos like f(ct) enough that they're in muscle memory.
- %
- esc is mapped to C-[ by default. I've been using esc, and am comfortable with it, but I'm starting to get used to this, and it's likely going to be faster in the future.
- block visual mode C-v is really useful
- some emacs-esque keys are available in insert mode. I use C-b, C-f, C-a and C-e quite often there
- I mapped C-j and C-k to do 3 j / k which helps me quickly go up and down a document
Beginner lessons (not for you, but in case someone else can be helped):
- Stay the out of insert mode. This is often my first tip for someone starting out with vim: you're not going to be comfortable until you find yourself being in command mode all the time and only incidentally in insert
- Never ever reach for the cursor keys. hjkl are there for a reason, and if you feel uncomfortable using them now, get over it, you'll thank yourself very soon.
Thanks for posting this question, because now I can ask this: For the vim masters, what changes really improved the way you worked with vim?
You can also rest comfortably in the knowledge that most vim and emacs users probably feel the same way, or so I assume. Anyone out there feel like their vim workflow doesn't incrementally improve? I don't think I've used it long enough to be a judge of this, but I find I'm getting better with use, though the improvement curve has definitely dropped off.
I think most Rails developers would agree with you there, which is why we're still seeing interesting gems that make our work easier coming out every day. There is a real commitment in the Rails community to make web development more productive and enjoyable, and I would hope that that is the attitude shared by most devs, regardless of framework.
Still, there is something very true to the original comment. Most web frameworks are wed to an overall philosophy for creating web applications. Rails is unlikely to depart from the MVC pattern for example. If you agree with that you can see that Rails, and any other framework I can think of, can at best hope to strive for a local maximum, unless their overall approaches are eventually validated as the way to do things, but I find that very unlikely.
I like the idea of web frameworks using functional languages, largely because I believe a framework written in a functional language will be better capable of adapting to new advances. I definitely agree with you about Sinatra. Even if a lisp or other FP language is better suited to the task, the advance will be evolutionary at best, while what I'd like to see is something revolutionary.
You're confusing Hashrocket, the web development company, with United Directories, the company being charged. The people being charged are essentially initial investors. Pointing a finger at Hashrocket in this scenario is not unlike blaming every startup that was invested in by an angel or VC that later ended up involved in fraudulent activity. None of this means that Hashrocket is not at all at fault, but based on the news that we all have, you're drawing unreasonable conclusions. If however you have other sources, please share them here, otherwise you're just trolling.