Vim vs. IDE (flame on)
-
@jsmith said:
@Joost_ said:
I bet you could customize Emacs and VIM to do all that. Then you'd editor technology from the 80s doing things from the 00s. That would be so cool. Kind of like fitting an anti-gravity device into a Fiat Panda.
[...]
No, this is still no excuse to go back to the 80s and run VIM.
So you're saying that dropping $60 on 1GB of RAM is a worse option than using EMACS and VIM, giving up an integrated IDE/debugger, refactoring, code completion, and a billion other things.
I'd say I'm totally not saying that. I think it should be pretty clear by now that I think VIM and EMACS are among the most unusable programs to litter the planet. :q!
-
Screw you all!
I do all of my Java in Windows Notepad.
-
@Joost_ said:
I'd say I'm totally not saying that. I think it should be pretty clear by now that I think VIM and EMACS are among the most unusable programs to litter the planet. :q!
Emacs I agree with, VIM is one of the most useful applications ever devised. I use it every day, it's often far faster and available than an IDE (think when using a remote Unix machine through a terminal emulator).
Every Unix machine has VI installed in some flavour, and so does every Windows machine I lay my hands on (though some colleagues are strangely reticent about it, insisting to use e instead).
-
@jwenting said:
Emacs I agree with, VIM is one of the most useful applications ever devised.
First, a little definition[1]:
devise, v:
- come up with (an idea, plan, explanation, theory, or principle) after a mental effort
- arrange by systematic planning and united effortNeedless to say, 'to devise' is a grotesque overstatement when it refers to a "useful application" like VIM. You might have written instead: "VIM is one of the most useful applications ever hacked together during a horrid LSD trip."
A tutorial and a thick manual is no replacement for a menu with shortcut keys[2]. And if you want scriptability, we have ....... wait for it ....... wait for it ...... SCRIPTS! Which run outside the editor!
[1] http://wordnet.princeton.edu/perl/webwn?s=devise
[2] I can almost hear a 1337 VIM h4xx00r say: "if you install plug-in quux you can type :m77xc and you have y00r newb menu har har omg lol noob".
-
@Joost_ said:
I'd say I'm totally not saying that. I think it should be pretty clear by now that I think VIM and EMACS are among the most unusable programs to litter the planet. :q!
I don't think that's true. Saying that both VI(M) and EMACS have an extremely steep learning curve is true, saying that they don't follow the UI principles and shortcuts of the Windows platform is just as true, but they're not "unusable" by a long shot. They require you to learn how they work from the beginning (while a Visual Studio or an IntelliJ allows you to start working pretty much w/o knowing anything about the tool), but once you've passed the learning phase and you've grasped the basic shortcuts and philosophy of the editor (nay, IDE, Emacs at least is one for sure, and a well configured VIM with a few plugins in doesn't lack much either) you're done, while with a Window-type IDE the learning curve is much gentler but much longer too.
-
So because you can use VIM after you learn all the shortcuts, it doesn't suck because you first have to learn all the shortcuts. Clever rhetoric, that. It's true that VIM and Emacs don't follow the Windows princples and shortcuts. They also don't follow any other platform principles because they're platforms unto themselves.
There's this new thing, called interface design. IBM put it nicely in their User's Bill of Rights[1]:
"10. Usability: The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use. In the case of VIM and Emacs, this right only applies after having learned the commands."
None of the hundreds of interface design guidelines on the net say: commands should be short and cryptic, hidden away in tutorials and manuals, to maximize the user's efficiency. Most do have a thing or two to say about switching modes all the time, and about learning curves as well.
-
@Joost_ said:
There's this new thing, called interface design. IBM put it nicely in their User's Bill of Rights[1]:
"10. Usability: The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use. In the case of VIM and Emacs, this right only applies after having learned the commands."
Don't mix up your vim-hate with IBM's 'User's Bill of Rights' - I see no reference to them on the link you provided.
All this wishy-washy 'User is King' consultant-speak is all very good, but vim is based on an editor invented in 1976 - you know, back when you had hair and I wasn't even born, and compilation was an overnight task. The fact that it's survived 30 years in basically the same form is a testament to its interface, its simplicity and its usability. It's just in 30 years it's grown a fair bit, and is now a little daunting for the unprepared.
Anyway, time for a group-hug moment - check out number 2 on the vim wishlist : http://www.vim.org/sponsor/vote_results.php
-
@Joost_ said:
There's this new thing, called interface design. IBM put it nicely in their User's Bill of Rights[1]:
"10. Usability: The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use. In the case of VIM and Emacs, this right only applies after having learned the commands."
And thus was Lotus Notes created.
-
Just crawl back under your PDP-11. Hope #3 on your list works out - VIMIM: all problems fixed, big and small, more robust!
-
@Joost_ said:
So because you can use VIM after you learn all the shortcuts, it doesn't suck because you first have to learn all the shortcuts. Clever rhetoric, that. It's true that VIM and Emacs don't follow the Windows princples and shortcuts. They also don't follow any other platform principles because they're platforms unto themselves.
There's this new thing, called interface design. IBM put it nicely in their User's Bill of Rights[1]:
"10. Usability: The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use. In the case of VIM and Emacs, this right only applies after having learned the commands."
None of the hundreds of interface design guidelines on the net say: commands should be short and cryptic, hidden away in tutorials and manuals, to maximize the user's efficiency. Most do have a thing or two to say about switching modes all the time, and about learning curves as well.
Interface design guidelines are generally meant to make a program as intuitive as possible to someone who is approaching it for the very first time. I am willing to accept a trade-off in intuitiveness for greater power. The learning curve for a program that's going to be used casually should be low. For something that's going to be used by a professional on a daily basis, I think a steeper learning curve can be acceptable. Perhaps I'm just odd.
sincerely,
Richard Nixon
-
a user interface should be intuitive and quick to use for the largest possible cross section of its userbase, not just for those unfamiliar with it OR for the powerusers.
The ideal user interface would adapt itself (or allow itself to be adapted) to the preferences of its users.
Windows for example now tries that with some success by allowing programmers to design their menu structures so that rarely used commands aren't visible by default. Though some people complain about it it's actually a very good idea (even if it doesn't always work properly, but it's not bad for a first itteration).
Another example would be having a choise of using either a wizard to guide the user through some process or a more flexible system where the poweruser can have more options that the average user never needs. This has been used in Winzip (among others) for almost a decade.
-
@Richard Nixon said:
Interface design guidelines are generally meant to make a program as intuitive as possible to someone who is approaching it for the very first time. I am willing to accept a trade-off in intuitiveness for greater power. The learning curve for a program that's going to be used casually should be low. For something that's going to be used by a professional on a daily basis, I think a steeper learning curve can be acceptable. Perhaps I'm just odd.
sincerely,
Richard Nixon
Well spoken, Mr. President! A overly verbose and simplified user interface made for beginners costs you valueable minutes every day if you are a poweruser; that makes it a very expensive tool in the long run.
-
@jwenting said:
Windows for example now tries that with some success by allowing programmers to design their menu structures so that rarely used commands aren't visible by default. Though some people complain about it it's actually a very good idea (even if it doesn't always work properly, but it's not bad for a first itteration).
That's the most stupid idea in UI design ever. (Other GUIs, like OS/X or the various Linux desktops, do not even offer that as an option, for a reason).
For a beginner, on of the most important things is consistency. Nothing worse that a userface that constantly changes itself.
For a poweruser, hidden options are annoying.
-
In this respect, the grouping in the XP taskbar is an atrocity.
Things are never in the same place and you're forced to try and recognize the
correct browser window via name, which is unreliable as hell.
Hiding 'inactive' icons in the tray is also a bad idea.
You don't hide status things.
You don't hide menu options BY DEFAULT.
All this "personalized menus" stuff is just bunk. It doesn't work.
I enjoy the option to hide menu items in Photoshop. But that's my choice, and I made it when I was ready.Windows for example now tries that with
some success by allowing programmers to design their menu structures so
that rarely used commands aren't visible by default. Though some people
complain about it it's actually a very good idea (even if it doesn't
always work properly, but it's not bad for a first itteration).
Programmers do not have that authority. Programmers do not know what a rarely used command is. Lay off my menus.
-
@llxx said:
You're supposed to have the design all thought out before writing any actual code. Programmers that make mistakes while writing code eventually lead to the formation of a few WTFs in attempts to "fix" it. It is entirely possible to write perfect working code on the first try. That's because you've already thought out what needs to be done in detail, and all that you have to do is write the code. Syntax errors happen only because the programmer isn't paying enough attention.
This works well in some situations.
Like in Wonderland, where people are able to decide in advance the way an entire application will work and exactly what their workflow will be, and get it all right on the first try.
Or where people can design a video game and decide in advance exactly what features they will or will not need, and what content, and what game mechanics, because they are so good that they can perfectly figure out what gameplay idea will work and what will not.
And they are so good that they'll be able to satisfy the holders of the IP the game is based upon on first try, too.
My problem is I live in the real world.
Specifically, I work in a company making video games, on a content edition tool. That means that I must need to add features and change stuff around to meet the ever changing requirement of content designers so that they can themselves meet the ever changing requirement of the game design. The game being an MMORPG, the whole design process is inherently iterative, as you can't really predict what gameplay features will work and will not and how they will need to be tweaked once thousands of players start beta testing the game.
There is no such thing as having the design all thought out before starting coding in these conditions. Part of it, certainly.
But in any case, believing to be able to get the design right on first try is incredibly foolish.
-
@ammoQ said:
@jwenting said:
Windows for example now tries that with some success by allowing programmers to design their menu structures so that rarely used commands aren't visible by default. Though some people complain about it it's actually a very good idea (even if it doesn't always work properly, but it's not bad for a first itteration).
That's the most stupid idea in UI design ever. (Other GUIs, like OS/X or the various Linux desktops, do not even offer that as an option, for a reason).
For a beginner, on of the most important things is consistency. Nothing worse that a userface that constantly changes itself.
For a poweruser, hidden options are annoying.The idea itself is sound. If a user never uses a function don't show it to him by default thus reducing the complexity of the user interface.
Maybe it should better not have been automated like it is, but that doesn't take away from the general idea being a good one.
-
@dhromed said:
Programmers do not have that authority. Programmers do not know what a rarely used command is. Lay off my menus.
Programmers are told what to do by analysts and architects who get told what to do by marketeers and managers who supposedly get told by customers.
We're the lowest of the low in any company and as long as that doesn't change we shouldn't be expected to fight bad ideas.
We'll not succeed anyway, and most likely will only get punished for speaking up against the idea of someone who has the ear of upper management.Been there, done that, lost the contract.
-
@jwenting said:
"never uses a function" is a self fullfilling prophecy when the UI starts hiding it. Unfortunately, e.g. in MS Word, there are too many ways to do something the wrong way.The idea itself is sound. If a user never uses a function don't show it to him by default thus reducing the complexity of the user interface.
Maybe it should better not have been automated like it is, but that doesn't take away from the general idea being a good one.
It should not be automated at all. I have no objection against a program that lets the user customize the menu.
-
@jwenting said:
Programmers, analysts, whoever.You get the idea.@dhromed said:
Programmers do not have that authority. Programmers do not know what a rarely used command is. Lay off my menus.
Programmers are told what to do by analysts and architects who get told what to do by marketeers and managers who supposedly get told by customers.
Point is, don't make my decisions for me when you don't knwo what my decisions will be, because you don't know it.
@ammoQ said:@jwenting said:
"never uses a function" is a self fullfilling prophecy when the UI starts hiding it. Unfortunately, e.g. in MS Word, there are too many ways to do something the wrong way.The idea itself is sound. If a user never uses a function don't show it to him by default thus reducing the complexity of the user interface.
Maybe it should better not have been automated like it is, but that doesn't take away from the general idea being a good one.
It should not be automated at all. I have no objection against a program that lets the user customize the menu.
Agreed.
-
@jwenting said:
@dhromed said:
Programmers do not have that authority. Programmers do not know what a rarely used command is. Lay off my menus.
Programmers are told what to do by analysts and architects who get told what to do by marketeers and managers who supposedly get told by customers.
We're the lowest of the low in any company and as long as that doesn't change we shouldn't be expected to fight bad ideas.
We'll not succeed anyway, and most likely will only get punished for speaking up against the idea of someone who has the ear of upper management.Been there, done that, lost the contract.
What company do you work for?
sincerely,
Richard Nixon
-
worked for more than a few, from small (4 people) to multinationals (tens of thousands of people).
Never noticed programmers being held in much higher regard than the gardener or the receptionist, not even in software companies.
Like it or not, we're interchangable work units and treated as such. Was a bit better in the late 1990s up to maybe 2001, but with tens of thousands of programmers out of a job there's no incentive to keep those that do have a job happy as they're easily replaced with local talent (and that's not even taking the massses in India and Eastern Europe into consideration).
-
@Otac0n said:
Screw you all!
I do all of my Java in Windows Notepad.
/agree
Notepad/Command Line Compile = The Win.
-
@SeekerDarksteel said:
Notepad/Command Line Compile = The Win.
I've tried, but the compiler can't understand my handwriting.
-
I use IDE's when appropriate, I do like all the bells and whistles in NetBeans (plus i'm usually to lazy to hand-cruft my own GUIs) but when I'm hacking at home I usually use Emacs. It does everything anyone could possibly need a text editor to do... AND I can check my email with it!
And just becuase of the name of this thread, I gots to do this:
Emacs > vim
-
Here's a bunch of assorted hot wind all in one post.
murphyman:
I thought I was the last person on Earth to start using IDEs. Seems there are still others out in the world who question the value of IDEs. Good! Keep questioning things.
You say if you need a program to tell you what's wrong with your code and autocomplete your method names, then you've got a problem. I agree completely. But once you know how to code and you know your libraries and so forth, the IDE becomes a helper and not a crutch. Why type the same method names over and over again? Do you enjoy typing that much?
I resisted using IDEs until they began to include features that I, personally, found useful. I like having a tool that integrates a debugger and profiler with the source editor, that has built-in support for a unit test framework, that can pop an import statement in for me, that has built-in support for check-in and check-out to/from version control, that lets me look up method signatures without having to open another window to look at documentation, and add packages to the classpath without having to use a different tool or a command line to do it. It isn't because I don't understand what the tool is doing for me. It's because of speed, convenience, and accuracy.
I like tools that include support for the standard refactorings, too. It's a great time-saver. Imagine manually moving a method from a subclass to a superclass in a large codebase. It would be an error-prone hassle at best, and beyond what you could do with awk or sed. No, thanks. I'd rather let an IDE rip through the codebase for me. It won't make any typos, either.
What I don't like to see is young programmers coming along who learned to code from inside an IDE in the first place. They tend to blur the distinctions between the features of the programming language itself and the features provided by the IDE. They also tend to have difficulty switching to a different IDE when they join a project team that uses different tools than they're used to. I think it's better for people to learn a programming language independently of any IDE, and then learn about IDEs later.
to many:
You sort of give away your age range when you talk about how bloated Java "is". I usually talk about how bloated Java "has become." Maybe that gives away my age range, too. Java didn't begin life in a bloated state. A lot of people have worked very hard for a long time to pump it up.
quamaretto:
You might like VSTS better than VS.NET. We've been using it in beta for the past few months. It has a new version control system built from scratch that takes into consideration the popular and proven-useful features of other version control systems out in the world. It's not based on SC at all. But VSTS is a big honkin' set of code. We use PCs with 2GB memory just to run the client components. Ain't no Java tools THAT bloated!
llxx:
It's a great idea to have the design all thought out before you write any code. In a perfect world, maybe that could happen. But the reason to refactor isn't that the design wasn't properly thought out in the beginning. The reason is that the design evolves as the team and customer learn more about the details of the requirements through iterative development and incremental delivery. Up front design is still necessary, but by definition it isn't "wrong" when teams discover the original design needs to be updated in the course of development.
Refactoring keeps the design (as expressed in the code rather than in a document) clean as things change. Without it, the code would change, but the structure of the code would still adhere to the original design. That practice incurs "design debt" or "design rot", a problem that grows with each release until an application becomes unmaintainable. When you extrapolate the problem across all the applications at a company, I'm sure you can see the effect on TCO.
You say IDEs sometimes get in the way of writing code. I agree. I'm pretty choosy about which IDEs I consider useful. Lately I've been working on a Ruby on Rails project, and I don't find any IDEs particularly useful. I'm keeping an eye on the rdt plug-in for Eclipse and on RadRails. I think the tools will mature, but as of today I use a text editor for that work.
You disparaged cross-platform languages and suggested programmers are too lazy to port the code themselves. Amusing, but misses a point, IMHO. Other than OS-level stuff or high-performance applications, I see little need to write to a specific platform these days. I mentioned our company has been using VSTS, but I'm not personally excited about it because it's a single-platform technology. As such, it seems to be aimed at the 1990s market. A cross-platform tool offers the customer the option to switch hardware vendors. That presents opportunities to scale solutions (say, from Wintel servers to Solaris or AIX) and, if necessary, to escape from burdensome license agreements. Business considerations trump coder-level preferences every time (sorry).
Stan Rogers:
>cAN'T wE jUST gET rID oF tHE cAPSLOCK kEY oNCE aND fOR aLL?
Don't know if this is just a legend or what, but I read somewhere that one of the original C guys, Dennis Ritchie or someone like that, went around their office one night and scraped certain connections off the insides of all the keyboards so that no one could type any upper-case letters. I guess that never caught on as a standard practice. Go figure.
Re: vi/vim etc.
vi seems cryptic compared to typical text editors because it was written to support programmers using X terminals on networks with 110 baud connections. It was very well designed for the realities of that era. No one set out intentionally to confuse people by writing a text editor that was hard to use. Do you really think anyone would do that?
-
@llxx said:
@quamaretto said:
You are saying,"If you don't always design everything perfectly at the beginning, you are stupid." Nice try. That's completely unsupported and incorrect. All programmers make mistakes, and some are mistakes that result in repetition or unwieldy code, and those things need to be fixed. Sometimes, those "mistakes" are the resulting of doing something twice or three times, intentionally, in order to how to go about building the abstraction.
You're supposed to have the design all thought out before writing any actual code. Programmers that make mistakes while writing code eventually lead to the formation of a few WTFs in attempts to "fix" it. It is entirely possible to write perfect working code on the first try. That's because you've already thought out what needs to be done in detail, and all that you have to do is write the code. Syntax errors happen only because the programmer isn't paying enough attention.
That perspective is fine, when you were the original developer of an application and work with it until it's dead and gone, but the fact is developers inherit code. That code may not have been designed/developed the way the new owner would have preferred and may warrant refactoring. To imply that code should never have to be refactored is to ignore, among other things, the history of the application, the devlelopment methodology (or lack thereof) under which is was developed and attrition.
