Hacker Newsnew | past | comments | ask | show | jobs | submit | ckg's commentslogin

According to this article (http://www.eurekalert.org/pub_releases/2012-12/nifm-sfe12061...) homosexuality is epigenetic and not genetic (i.e. is not related to a specific gene, but to chemical differences that affect the expression of genes).


I think thrust counts to a degree, as you'll lose velocity from gravity drag if the time to orbit is too high. The degenerate case would be if your thrust is less than the weight of your rocket (i.e. not moving).


This strikes me as the old nature vs. nurture debate - trying to determine which human behaviors are hard wired and which are learned. Like most complex questions I don't think there is a single right answer, but my current theory is that humans have more hard wired behavior than most people like to admit. It is precisely because of our language skills that we can rationalize behavior that has it's root cause in the more animal regions of the brain.

To put it another way - most people think they are rational. Most people act irrationally. To me it is animal instinct that is cause of greed, war, social hierarchy, etc. and it is so ingrained in society that we don't question it's root cause which most likely boils down to atavistic tendencies.


If they feel strongly enough about it to leave a comment then I think it's safe to say it does hinder their enjoyment - in the same way that obviously broken things distract and displeasure in any medium.


I wonder if this has anything to do with the shifting of industrial jobs to other countries as well? Maybe when more tangible goods were being produced in the US there was a higher respect for science/engineering, which is in large part a study of the tangible (or physical). Now that many jobs in the US are financial, legal, etc. there's more of a disconnect between what people see as the basis of the economy and what scientists are studying.


I can say for a fact that Israel has very little heavy industry of its own, but its tech sector competes with agriculture for #1 sector in the economy and its R&D spending as a percentage of GDP is (IIRC) first in the world.


Screwdriver - quick, cheap, easy to use, intuitive. Can be learned once and carried around with you.

Car assembly line - lots of initial capital, specific to one kind of car, lots of time to learn.

Seems like a valid comparison.


The point is: these comparisons always try to make vi seem like the always better choice INSTEAD of an IDE and this is were I completely disagree. And you make it look just like that with adjusting the comparison in favor of vi, the screwdriver. This is just wrong. Let's see, you could also say:

Screwdriver: specific to only one type of screw, limited to only a couple of similar sizes and all you can do is drive screws in and out or maybe stab someone.

Assembly line: way more complex and needs some setup time but you can do WAY more things with it, way faster, way more efficient once setup, especially on a larger scale. It can drive screws in and out, solder, cut, fold, package etcetcetcetc. Pretty much anything you set it up to.

So, vi is a horrible replacement or alternative to use in the typical huge Java (or what have you) e.g. web app projects where things like auto completion and easily getting from one class to another, built-in compiling, debugging, refactoring, source control etcetcetcetc really start to make your life easier. vi on its own cannot offer you that, not even remotely... then you need a shell and other programs to do all that. And there are no alternatives to most of the tasks an IDE can offer you help with.

vi is definitely nice for editing files especially on a slow line and as a general purpose editor - but it is no replacement for an IDE and the comparison that it is "better than an IDE" might only apply for exactly one task: editing files. IDEs offer you tons of other things. So it is just wrong to compare to two or present one as a replacement for the other.


If I thought an IDE was better for large Java projects than vim, then I'd use an IDE instead of vim for large Java projects. You'll find that many vim users do not use an IDE because they've found it to be more productive for them to use vim + command line instead. In those cases, there is clearly a choice being made about IDE versus vim. If you want to be pedantic about the fact that vim is just a text editor, then just imagine that whenever someone talks about using vim instead of an IDE or compares vim to an IDE, just replace "vim" in your head with "vim + command line". If you do this, you will better understand what they're saying and you won't have to get on the apples-and-oranges soapbox quite so much.


Great article on this very point: "Build an IDE with tmux and vim"--http://alexyoung.org/2011/12/19/build-an-ide-with-tmux-and-v.... The money quote: The difference between this approach and a traditional IDE is this interface adapts around my current task, and is only limited by the thousands of commands and scripting languages that I have installed.


Except then I still don't have any interface builders, out-of-the-box code completion and on the fly compiling/checking for small mistakes, easy navigation through class hierarchies ("click on Classname, function etc..) plus showing me documentation alongside, refactoring tasks, all sorts of useful and some useless wizards etc. and we haven't even talked about more specific things like developing for iOS. So IDE is still ahead in terms of what it has to offer me that not even vi+console or vim+console can. My point stands.


I fully realize the advantages that an IDE has over vim:

http://news.ycombinator.com/item?id=2938995

If your point is that this handful of advantages is a slam dunk, and that it makes IDEs and vim+console incomparable such that whoever does so is making a categorical error, then your point has no legs to stand on.


You belittle clear advantages simply because they do not fit your taste or style while the usefulness and spreading use of IDEs is unquestionable, so this is too much of a personal preferences discussion than anything else, just like all vi vs emacs flames have always been and I find it disappointing that in 2012 this STILL keeps coming up... I thought I had FINALLY left those zealots behind me in the 90s. And I really do not like your tone.

I am more than sufficiently "fluent" in pretty much all common IDEs and in vi(m)+console so that I don't really care which one I am using or have to use neither do I care on which OS... most of the time I end up in a good IDE because for a lot of the tasks I want to do and get paid to do, there are no real alternatives in vim+console, they might be specific though.

The article argued vim's superiority in editing so comparing that to an IDE really are two completely different things. Comparing vim+console to an IDE is always going to be all about personal preferences and which extensions do you use in the one or the other, which tools/options/tasks are available and which aren't - but ultimately they cater to two usually very different crowds: the console-lovers and the oh-shiny-clicky crowd and you will find it very difficult to even remotely describe an advantage of the one to a member of the other crowd... and that's where the comparison doesn't add up and feels to me like apples-oranges.


Comparing vim+console to an IDE is always going to be all about personal preferences

That's been my point from the beginning. Tradeoffs between personal preferences is a hallmark of apples-apples comparisons. I mean apples-apples in the sense that both toolsets are used to accomplish the same exact things. I agree that there are the two general types of people that you describe, but I disagree that they are so irreconciliable that they shouldn't even attempt to discuss the tradeoffs. It is a perfectly reasonable discussion to have.


Solution: Use an IDE plugin for vi-style bindings.

Dudes on assembly lines use screwdrivers.


You do realize, the article is written by a guy who sells a vim emulator plugin for Visual Studio?

(It's really good, too, I use it at work.)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: