I feel the same way sometimes too. One thing to consider though is that when the overall complexity of a project increases these little things do add up.
I've had some pretty good results with Scott Young's ebook and blog in general: http://www.scotthyoung.com (ebook is on the side of the page, can't find a direct link to it).
My goal is to achieve the same goal, except with n-number of subjects (math, science, humanities, the arts, etc) over x-number of years. Thanks for the suggestion!
I wonder how many (and which) CS texts are recommended simply because they are considered "classics." As a beginner there is really no way to tell how good a book will be before reading it without relying on the word of others.
Math has overlaps with CS. There's surely justification for taking extra CS classes as part of your math degree. Data visualization requires knowing some computer graphics (and some art theory), automata theory is very math oriented, numerical methods of course requires programming (but the boring sorts of programming that CS departments don't usually teach).
If you want to go more into sys admin, then does your local math department need help with their system maintenance?
Some universities have a track or certificate in "computational science", and the EE department might also have CS-like courses.
My biggest regret about my undergrad education is that I didn't do a summer internship. Now is the time to apply for this summer; perhaps you'll find something interesting.
"For chess, deliberate practice includes deep analysis of grandmaster games."
If this is true, could studying (reading) good code do the same for programming? One could, for example, begin to write an application and find code to a similar application where they would be able to check why things are implemented a the way they are as they go along. The tricky part here is deciding which code is worth studying.
I believe "read good code" is already standard advice for improving your coding skills. However, I think there are many differences compared to studying chess by analysing games.
One way that it works for programming is doing small exercises and then checking the answers. For instance, the 99 Problems in Prolog (or its translations to Lisp, Haskell, etc):
But as you say, for larger problems it's harder to find good "answers". Even for something relatively small like unix utilities. Say you want to write cat or echo. You get source code from BSD and GNU and Solaris and they're quite different from each other (I recall seeing a comparison somewhere, mainly putting the GNU code in bad light, perhaps unfairly. Anyone has the link?).
This is why I haven't yet read all of Peter Norvig's coding essays -- you can depend on him to publish code that's really hard to improve on (by the metrics he's writing for, like clarity). I like to write my own first before reading someone else's, because yes, it really does help you suck the juice out of a learning opportunity. Feynman and Turing both seem to have emphasized this too.
Really polished code is hard to find. I've been playing around off and on with Ken Thompson's regular expression search paper most recently.
I feel that the end result of polished code isn't useful unless you can see the process they went through to get there. It seems difficult to retrace their footsteps.
I've found that extra info to be interesting and useful, it's true, when I can get it. For instance, Norvig's Lisp-in-Python essays came out with the code still in some flux and I could compare his improvements to mine.
I will definitely like to do some non-programming things on the side, such as read some books I've been meaning to and perhaps some martial arts as well.
These next few months will be a good time to explore.
Isn't this just because he is more experienced in Vim? I'm not an expert in any case, but is it really true that Vim is that much faster (editing-wise) than Emacs?
I'm guessing that everyone's editor of choice would be the one they're most comfortable in. In other words, the one in which they've invested the most time into learning.
I use emacs for everything except to quickly jump around a file and edit it. Vim is super fast for this.
Emacs will also help you when your in weird situation because it is so powerful. One very simple example: we had some new machines installed recently but they didn't have our home directories nfs-ed onto them because the San was in a different network. With e-shell In emacs I could copy over my files without even opening a window to my home directories because emacs's tramp mode is built into the shell. It meant that I had autocomplete in my shell while working on a remote machine. Guys were ftping files clumsily over while I just had to use "cp" and the tab key.
Assuming you use emacs in the first place. And not everyone does, or cares to. Especially when there are alternatives with a much easier learning curve.
I dunno, I'm a longtime emacs user/addict, and I get the feeling that its actual editing commands just aren't that well thought out -- because of this, I've flirted with trying to use vim and vimpulse (an emacs vim emulator), but it's super-hard to get away from emacs once you're used to it...
I'd be interested to hear if anyone else has moved from emacs to vim. (Or thoughts of people who've gone the other way.)
I dunno, I tend to prefer the emacs movement keys over vim. I-search to move around in emacs, in combination with C+A+f/b is (usually) fairly fast - though a fairly good reason for that might be because I know the structure of what I edit. As for someone who moved from emacs to vim, I cannot resist posting this particular link :)
Well, I could be wrong, but it's just a sneaking feeling that vim might be faster. But I've never been able to stick w/ it long enough to know for sure....
But e.g., stuff like "." the e/E and b/B distinction, [d]f (like zap-to-char but waaay more useful) don't really have emacs equivalents.
And come on, C-f, C-b, C-n, C-p to move around -- not smart! I assume it's for "forward, backward, next, previous", but you shouldn't choose your most basic motion keys to have memorable names, you should choose them to be efficient!
In emacs, repeat is C-x z, and then keep pressing z. (C-x zzzzzzzzzzzz...)
While M-f, M-b are e and b, I don't know of an exact equivalent for E and B. But they could very easily be added.
IMHO, basic editing in Emacs has slightly higher constant factors (mostly due to typing the modifier keys), but scales much better as operations become more complex.
Cool tip about C-x z, buuut... Playing with it a little bit, it doesn't seem to fit so well with a non-modal editor, because "last command" ends up being more like "last keystroke". E.g., if I write "I like cats" and then hit "C-x z", it enters..."s". Probably a more practical emacs equivalent is to just quickly record and replay a macro.
As for adding equivalents to E and B, sure, but what keys do you bind 'em to? Either unwieldy C-c FOO combinations, or spend the rest of forever playing whack-a-mole with various modes that happen to have already defined the keys you wanted to use. While emacs is infinitely customizable, the baseline editing functionality that everything expects is important -- otherwise you're just fighting against the grain. Though the various vim emulation modes have made a heroic effort...
It would be interesting if something like that vim keystroke competition could be expanded to include emacs as well. >:)
The repeat has different granularity. I prefer Emacs's, but, matter of taste I guess.
"Super"-f/b are free on my keyboard, where "super" is the button with the Windows logo on it. I don't really miss the E/B functionality, though, and I used vim for about five years before I started using Emacs.
I know this is a late reply, but you're very right about C-x z and vi's . having different groupings. I'm so used to defining keyboard macros for any operation I want to repeat as a whole that it didn't even occur to me.
I'm easily sucked into vi / emacs threads, and I've talked about this at length a few times. I have a bit over five year experience with each, at this point. I prefer vi's general keyboard interface design (edit vs insert mode, etc.), because it gets rid of most of the modal keys that Emacs uses, but strongly prefer Emacs's "continuous environment"/integration and general extensibility. On the balance, I prefer Emacs. (And while there are vi-emulation modes for Emacs, such as viper, few extensions provide vi-like keybindings for them.)
For "." you could say that C+k,C+_/C+y does most of what I want done -- and arguably, the more complex cases might be amenable to using regexp-replace.
Regretfully, the only time I ever use hjkl is to play crawl :) The emacs keys are perhaps more geared towards using modifiers, with M-f/M-b + C-f/C-b serving as the closest replacements for movement, and M-z for zap-to-char.
Faster startup ain't nothing! I'm religious about making my .emacs only load modules on demand (using autoload and eval-after-load -- lisp is a great editor customization language, actually), and have managed to get emacs down to 250ms:
gin17 ~ $ time emacs --eval '(save-buffers-kill-emacs)'
real 0m0.256s
But that's still a lot slower than instant, which is where vim is:
gin17 ~ $ time vim --cmd :q
real 0m0.006s
I definitely don't feel that emacs editing is bad, and I use and appreciate one-off macros, [regexp-]-isearch-and-replace, and killing and yanking (the kill ring is awesome), but...I think the grass might be greener.
Well, after all this discussion, I'm probably morally obligated to spend more time with vim (or maybe vimpulse) so that I actually know what I'm talking about. :)
Yeah yeah yeah, emacs is infinitely customizable :) (and you can even emulate vim), but...this doesn't work out as well as you might like in practice 'cuz there tends to be a lot of friction with various modes that weren't expecting your customizations.
Plus, I'm already not sure if the time I save in emacs is worth the time I lose fiddling with it ;)
Cool, I will just simply tell you my opinion, in the end it is you who should make the decision, for me school is for people who don't have imagination and courage to learn by themselves. But in early age and with lack of experience it is easy to get carried away and take the wrong direction.
If you already found your passion and you are sure that whatever is it, it is what you want to do for next few years of your life. Take the 6 months off and go explore in that direction and see what you get. Otherwise if you are not sure yet, stay in school and try to find what you like to do, you still have long way and if the next 6 months are not them, be patient sooner or later you will find what you like to do. Then everything is going to be clear.
Explore and try to meet people and talk to them whether in school or off school.
