Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[gogis]

Randomly found this:

http://matt.might.net/articles/what-cs-majors-should-know/

Do you people agree with the long, pretty specific list of things? o_O Just wondering, as I have little experience relative to many people here.

For an CS evangelist, probably, for practical programming this list is godawful.

Also some points is ridiculous, like this bit about emacs/vim against IDE. You know, most mundane tasks is tens times faster in IDE than in vim, whatever this ridiculous purist jerks tell you.

Also, what is your point? You can't become high paid evangelist, like Fowler or such from a scratch, so make you career as a fellow coder first.

From my perspective (senior programmer for 8+ years, web) to be a succesfull member of any software team you need, from top to bottom

- Get a communicative skills. This is the most important part - nobody likes to work with a jerk. You can be aspergery but you can't be an ass.  I've seen multiple guys laid off that way, and they was very capable coders, amazing, some of them. Team microclimate is the most important thing.
- Get the difference between functional and procedural programming and choose your future area of expertise. It's very distinctive fields and choose what you like more. You know, haskell and scala is used in very different areas than PHP and python.
- Decide what you like more - waterfall model or a agile. Again, that very important what workflow you prefer most. Difference is huge.
- Learn your main language thoroughly. I can't stress that enough, your language is your main tool - you need to know all the quirks and pitfalls of it. You need to know several languages, or atleast being capable to read it with understanding, but you absolutely need to champion your thing - that's the way you earn your senoir title and getting money for it. On my job I write on PHP, perl, python, js(jQuery, coffee, underscore) but I defenitely spend most of my time perfecting PHP, because thats how I earn my paycheck. Nobody needs jacks of all trade, masters of none.
- If you work with databases - learn differences between RDBMS and nosql, learn main dogs in these areas and learn your company database thoroughly, all the way up to optimization and profiling.
- Your job specifics. I can't tell anything about software development, but I can spend hours discussing highload matters, know your tools, everything about caching and replication and sharding and many other words related.

[GlyphGryph]

I think 10x faster in an IDE than vim is... probably bullshit. Like utter bullshit. Unbelievable bullshit even. Vim is a pretty powerful tool. While I'm not going to say it's necessarily better than the best IDEs or actually even worth picking up, it's notably better than some of the crappier ones and certainly not 10x worse than the best.

Anyway, the list is a actually a pretty good one, in my opinion and experience. It prepares you for a variety of tasks and situations and gives you strong foundations no matter which direction you go in. It, like gogis, emphasizes how important communication is, and thats something I agree with.

Note that this is to be proficient in computer science, and you'll need most of them. You can become a proficient programmer while skipping many items on this list, because most programmers don't need as much versatility.

And no matter what you do, you'll need to eventually develop one or more focuses which you really should know inside and out. It might be a particular language, as gogis mentioned, but it doesn't have to be.

[gogis]

I think 10x faster in an IDE than vim is... probably bullshit. Like utter bullshit. Unbelievable bullshit even. Vim is a pretty powerful tool. While I'm not going to say it's necessarily better than the best IDEs or actually even worth picking up, it's notably better than some of the crappier ones and certainly not 10x worse than the best.

Anyway, the list is a actually a pretty good one, in my opinion and experience. It prepares you for a variety of tasks and situations and gives you strong foundations no matter which direction you go in. It, like gogis, emphasizes how important communication is, and thats something I agree with.

Note that this is to be proficient in computer science, and you'll need most of them. You can become a proficient programmer while skipping many items on this list, because most programmers don't need as much versatility.

And no matter what you do, you'll need to eventually develop one or more focuses which you really should know inside and out. It might be a particular language, as gogis mentioned, but it doesn't have to be.

My vim comment was based on my experience, sitting behind my colleaguaes whose was vim proponents and watching their job. It's was horrible experience in my eyes. Vim is very powerful working single file and totally sucks when you work several thousands files project with alot of operations like opening/reopening many particular files or searching over project. Cmon, when I search my jetbrains project its takes 3-4 seconds, even with regulars. What you do otherwise? Grep'ing over directory? Maybe I am misguided and stale but from my experience powerful IDE can do everything vim can do, plus much more. Thats why I smirked reading this file. I perfectly know how to work with unix from command line. Vim? I have much, much better tools.

And I think that starting programmer only needs to know exactly one language he working with + some extras as a plus. Probably I was misguiding and offered not a starter package. But if you aim for a senior - this list was arguably spot on. Debatable of course.

And dont take my vim/emacs comments seriously. I am kinda against of all this geek programmers culture - I think it's unjustified and generally stupid.

[GlyphGryph]

In my experience most IDEs turn working remotely into a headache. And the vim most of my coworkers use is perfectly capable of doing the things you've described better than most IDEs. Of course it's not vanilla out-of-the-box vim, but that's still my goto tool for operating remotely through ssh, just makes things easy. And many of the best IDEs I've seen are, in fact, vim-based, and you would need to know how to use vim to do much with them.

But personally I think as long as your editing tool is capable of doing what you need it to, its a relatively unimportant part of your career.

[Willfor]

goto

Silly GG, you shouldn't be using goto's.

...

Okay, I will go off to the shame corner now.

[gogis]

In my experience most IDEs turn working remotely into a headache. And the vim most of my coworkers use is perfectly capable of doing the things you've described better than most IDEs. Of course it's not vanilla out-of-the-box vim, but that's still my goto tool for operating remotely through ssh, just makes things easy. And many of the best IDEs I've seen are, in fact, vim-based, and you would need to know how to use vim to do much with them.

But personally I think as long as your editing tool is capable of doing what you need it to, its a relatively unimportant part of your career.

No, it's really not a problem with good IDE's. They all work with SSH or over mapped disk just fine. And yes, all good IDE's have vim functionality embedded, which already defies your point.

And for an example, I will test you how I tested my colleague a year ago (I dont deny this functionality not in vim, I just dont know).

I need to quickly open file called RemoteUserController.php in my IDE.
In my phpstorm I do Ctrl+Shift+R then type RUC then enter and then I am in that file.
Does vim have that capability?

[GlyphGryph]

Willfor, I lolled.

And gogis, I'm not talking about IDEs with vim functionality, I'm talking about all vim IDEs.

Anyway, the versions my coworkers use work similar to the way you just described, yes. Some path information would usually be required because we've got plenty of files that start with the same letters or even have the same name (for good reasons I don't want to get into here) but that's not a product of the tool. Others would point and click at the file tree to open up the file in a new tab in vim.

(Mine might be able to do that but I personally wouldn't, as I am sure I have a very different workflow from my coworkers and from you. It wouldn't be much more difficult for me even though it would be quite different result-wise.)

Either way it would be trivial to set up vim to work exactly that way, but the "find file by case" thing honestly seems kind of dumb.

[gogis]

But personally I think as long as your editing tool is capable of doing what you need it to, its a relatively unimportant part of your career.

Thats a huge mistake. My job is mostly to refactor and optimize code. Make goods out of shit. You know, all that highload crap. Most of the times when you work in big company - you work with shitload of native, outdated code, written retarded sometimes. This require alot of work with set of files. You know, find all of copy-and-paste, wrap functionality, rewrite chunks of code. It's not a pretty. IDE is a must here.

It's never editing. It's finding and eliminating. Finding dependencies, mass refactoring(which vim lacks of).

[GlyphGryph]

Yeah, I've got no clue what you're going on about. I think it pretty much comes down to "You don't know how to use Vim" which is, y'know, fine, if you've got a tool that works for you, whatever. Because Vim can (and emacs can that and more), yeah.

[gogis]

Anyway, the versions my coworkers use work similar to the way you just described, yes. Some path information would usually be required because we've got plenty of files that start with the same letters or even have the same name (for good reasons I don't want to get into here) but that's not a product of the tool. Others would point and click at the file tree to open up the file in a new tab in vim.

I talk about tens of thousands files. Obviosly we have like twenty Storage.php files, but I can select needed one out of list provided by IDE. Vim just can't do it efficiently. Thats why I dislike that notion in the file I read. You can be much more efficient with learning all capabilities of your IDE of choice, instead of wasting time on vim. And yes, I am pretty adamant about learning vim is a waste of time. So many hotkeys for editor which is not best for your work? No. Not efficient.

(Mine might be able to do that but I personally wouldn't, as I am sure I have a very different workflow from my coworkers and from you. It wouldn't be much more difficult for me even though it would be quite different result-wise.)

Either way it would be trivial to set up vim to work exactly that way, but the "find file by case" thing honestly seems kind of dumb.

vim or even mc(i know people crazy like that) is not trivial to setup exactly that way, because installing good IDE require exactly nothing.

Btw I really dislike it's degraded into "vim or die" (it's same as PC vs Mac in my opinion), because I think other points I mentioned in my post is more important.

[GlyphGryph]

And what I'm saying if you've got a tool that does what you need it to the way that you need it to, you're fine. You seem to be experiencing some serious vim-hate for no logical reason that I can see, just because it's not the best tool for you.

No one in this thread has said anything about vim or die - it's just been you going off about how much vim sucks, in response to a suggestion that people should at least be familiar with how to use it (mostly based on it's presence as a ubiquitus unix standard that is practically guaranteed to be set up on any system you encounter).

Yes, a specialized tool for your particular task is likely to be better, but it's not like you're going to suffer for knowing how to use vim or emacs.

[gogis]

And what I'm saying if you've got a tool that does what you need it to the way that you need it to, you're fine. You seem to be experiencing some serious vim-hate for no logical reason that I can see, just because it's not the best tool for you.

No one in this thread has said anything about vim or die - it's just been you going off about how much vim sucks.

Vim is definitely does not sucks. It's a magnificient editor.
Web page saying that you need it to be a CS engineer - do. Big time. Huge fail. Incredible lie.
What I said wrong exactly?

[GlyphGryph]

Its a list of what you should know as a CS Major, NOT as a Software Engineer. It also doesn't say you'll need it, it says you should know it (big difference, you should know lots of things you don't need to know)

The document is intended to position you to seize basically every opportunity that comes along, from my reading. Vim is a useful tool for that. Nothing on this page is mandatory to be a successful software guy, even a senior guy. Everything on this page is useful as a tool in your arsenal for getting there and will help you take advantage of opportunities along the way. Vim and Emacs are both ubiquitous across unix-based systems, and they are one of the more common bits of technology among organizations that use them - learning them is definitely a useful thing, and I've got no problem with them appearing on this list. They also encourage a mentality that is useful for Computer Scientists even if they don't end up using them in their job BECAUSE they don't just hand everything to you, but expect you to use it as the base of a tool customized to fit your needs. The document emphasizes in multiple places how important it is to do things from scratch at least once, understand how and why the pieces fit together and fit them together yourself. Something like Vim is an extension of that and useful to know. He makes it quite clear that you're learning it to familiarize yourself with the philosophy, not because of it's usefulness. Even if you don't adopt the Unix philosophy yourself, familiarity with it is extremely important if you want to keep doors open moving forward.

It's not needed and I don't think the document says otherwise. Much like learning Racket, it's about the benefits of learning the tool rather than needing to use the tool moving forward.

[lue]

Based on how I use them, vim is good for quick, in-terminal editing of a single file, and emacs is better at everything else .

A bit more seriously, I think it's a good idea in general to go IDE-less at least for a while. It will help you understand more of everything that's not typing text into a file (compilation, debugging, etc). Worst that happens is you appreciate your preferred IDE's bells and whistles more .

I find it interesting how no-one's really discussed the merits of emacs yet. It's very different from the likes of nano, ed, vim, etc. It's so featureful that many joke that emacs is their second operating system. You can do everything from talk to a terrible psychologist to checking your email, and of course programming. Some language modes in emacs integrate the compiler and other utilities, allowing you to use it as an IDE if you wish. (I don't wish to start another battle in the holy war; I just wanted to point out emacs since no-one else had yet done so.)

Spoiler (click to show/hide)

Besides, can your vim or IDE unleash the powers of the butterfly?
(M-x butterfly for the interested.)

[ECrownofFire]

Not to mention you can have vim in emacs.

I haven't used either one, but saying that they don't have everything that an IDE has is really quite ridiculous. I know you can easily have multiple displays, folder trees, etc. on vim. It's like a GUI without mouse support, just like Dwarf Fortress!