duckpunch
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.
PHP has closures however.
A fellow who comments here http://avramc.posterous.com/united-directories-federal-court... makes a similar claim from a much more advantaged position of knowledge.
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.
With the amount of traffic their apps receive it would be quick and easy to achieve statistically meaningful data with a simple A/B test on a release.
I personally hate any animation in a UI unless it appears as a direct consequence of my actions.
Given that history, would it not be wise to complete a PhD to make sure you're not having the same mistaken thought once more?
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.
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)
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.
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.