On the one hand, I'm pleased that someone is posting this in the new-fangled bloggy tutorial style popular among the youth of today. It's nice to see my preferred environment evangelized.
On the other, it's a giant facepalm that the simplest, best documented, most powerful development tradition of the last 40 years actually needs this treatment. That there is a whole generation of developers who come out of school thinking that "building" is the action of pressing a button in an IDE GUI (and that "writing a program" means launching a big wizard that pukes a dozen files into a new directory) is just depressing.
My problem with make and autoconf, as a young student, was the difficulty of finding quality, intermediate examples. Textbook examples were trivial, professional examples were too dense to understand. There was nothing to bridge the gap.
Trying to read the configure scripts and Makefiles for software like Apache httpd server was overwhelming. There's obviously many man-months of work there as well as unknown styles, conventions, and tricks.
How (and why) would I go from "gcc -lexample -o program csci201.c" and maybe a simple Makefile to a 10,000-line ./configure script? I never had any idea.
> thinking that "building" is the action of pressing a button in an IDE GUI (and that "writing a program" means launching a big wizard that pukes a dozen files into a new directory) is just depressing.
I use UNIX as my IDE almost exclusively. When it comes to Java however, I don't think there's any way to avoid using Eclipse or Netbeans or something. Any nontrivial Java project is going to be convoluted enough that using the traditional tools is an exercise in futility.
Understanding the process of building has zero to do with knowing how to type make, or knowing the exact command line parameters GCC needs. Confusing a few cli commands with the process of building is just as bad as believing in the big magic button.
> That there is a whole generation of developers who come out of school thinking that "building" is the action of pressing a button in an IDE GUI
Why? I mean, the fact that a newbie developer just needs to know how to press one button to build their code is actually pretty amazing. Plus, how many school projects are complex enough to require much more than that?
i've been developing under linux since 1993, and i would love it if building were pressing a button in an ide gui (without having to drag the rest of the ide development process along). it seems like a genuinely superior development model to me - write your code, have your dependencies figured out automatically, and hit a button to build. writing makefiles by hand is just a sign my toolset is not powerful enough, or my language insufficiently well designed to automate dependency analysis.
I take it from reading this and other posts that cutting my programming teeth by learning to code in gedit and the command line, sans dev tools, is a good approach then?
I don't want to dis IDE makers. There are folks such as jetbrains that make an amazing product. But at the end of the day, for us linux-type professional developers, it's all text. You have maximum leverage with unix text editing tools. Refactoring 50 files at once by doing something like:
grep -lR 'old_method' | xargs sed -ie 's/old_method/some+other()+expression/g'
is just plain awesome. Want to find out what libraries a process is using?
cat /proc/$pid/maps
Want to find out where that process is logging to?
ls -hal /proc/$pid/fd/
Basically it's often hard to use a gui ide to accomplish an arbitrary task if the IDE wasn't built for it, or if no one has taken time time write plugins. At the risk of gushing, the command line is just one of the most extensible, composable environments ever invented, and it's success over the past 40 years proves it.
It's all text is the lowest form. Renaming a method by mass replacing text won't always yield the correct result. A tool that understands the language represented by the text can do a much better job. Also right-clicking on a method name, clicking rename, and getting a preview I can manipulate seems far more efficient.
But you are right, if an IDE wasn't built for a task you're SOL and you can likely compose something together on the command line to solve it.
I really love console, but I don't think that command is so awesome (don't tried it so I'm asking just for curiosity): What if you only want to refactor Class1.Foo() method while not changing Class2.Foo()? That is, could you refactor taking context into account with the CL?
I use Visual Studio to develop for WP7, and refactoring is even more awesome: change any name, click the little popup (non-intrusive at all) and select refactor. Done. Not only in that file, but also in your project and any other project you have opened.
I'm not trying to bash command line tools (I'd really love to know them better), but I think that there are things that are far easier with a graphical IDE.
While I generally use sed sparingly because of testability issues, I agree with the general point. The UNIX console tools are extremely powerful for text processing and graphical IDE's don't even come close. I have never found a graphical IDE that could match even VIM in text processing.
Sure maybe it adds a file browser or a couple of menu commands for building and running. But in terms of actual coding, VIM rules (I am sure EMACS fans feel the same way about EMACS and for similar reasons).
The selling point of an IDE is generally that it's "integrated" whatever that means. The selling point of UNIX or Linux is you can string the tools together, loosely integrated, to accomplish a better job, but it's not integrated in the same way out of the box.
I don't think there is any question that the UNIX approach leads to better productivity in my mind. The issue is that like all high productivity tools, it has a learning curve.
I agree that many underestimate the power of bash for development. Make, in particular, is much more widely usable. However, there are some things that I find very convenient in an IDE that are harder to do at the command line. Finding usages of a name (variable or function); finding the definition of same. Renaming same throughout the code base. Yes, I know about "find | xargs grep", but it's a bit more convoluted than IDE usage. Maybe I just don't know enough. Can anyone point to command line or vim tools to accomplish these tasks? Code analysis and warnings are another thing IDEs seem to do better.
I'm going to be a tad pedantic and note the following:
- bash and make are completely separate programs. As a matter of fact, I spend half of my time developing with ksh and Solaris make. The two programs you mention don't go 'hand in hand'.
- `find | xargs grep` is a terrible construct. 99% of the time (if not a lot more) you'd prefer using something like `find -exec`, I have yet to come across a version of `find` that wouldn't work that way.
My point is not to be an arrogant prick, and criticize the parent post. These kind of misconceptions usually indicate poor understanding of the larger Unix philosophy. By her own admission, my parent "just do[es]n't know enough".
I believe that in order to truly use Unix as an IDE, one has to go beyond the (arguably bad) reflexes taught by common GUI IDEs. It's not simply a matter of "What command can replace feature X from Netbeans/Eclipse/Visual Studio/...?" Modern IDEs weren't conceived with sed/awk in mind, aren't (for the most part) scriptable like most Unix shells are, and aren't sitting on top of a freaking Lisp machine like emacs is (you know the whole enlightment deal, lisp is superior, bla bla bla).
I am sounding like an evangelist, Unix tend to do that to me. I am trying to make a simple point:
It's normal to feel that something is missing if one is simply transposing her knowledge from point-and-click IDEs to the Unix shell.
(To answer your question, a combination of sed and awk does wonder to rename across the code base. And SO much more ...)
This is a significant reason that many Unix hackers prefer languages like C or Common Lisp where the same symbol means the same thing system-wide. Plain text grep, sed, and ex commands make refactoring quite simple and don't require fancy plugins to figure out what a name means in a given context.
You're looking for ctags or cscope, the first of which is mentioned in the blog. As for code analysis and warnings, surely that's a property of the compiler being used?
This is more or less exactly my approach. gnome-term, vim, and since this is a web app, a testing environment of Apache, Chrome and/or Firefox, etc. Between proper usage of vim, shell tools (grep, find, etc) svn, etc. I can put together the best of breed tools to form a really, really good development environment.
Thanks alot for that link, it lead me to this very interesting talk by Brent Victor, as kind of a counter argument to that principle: http://vimeo.com/36579366. And holy shit does he have a point. Many of today's programmers seem to be trapped in the thinking that the unix and vim principles are the holy grail, forever to be pursued, never to be changed. Isn't it time we stand up and reassess the tools we have? And I'm not just talking about the teleprompt generation tools like unix and vim, but also today's IDEs that have basically evolved as extensions to those tools.
It's interesting because usually HN would detect the link and redirect you to the previous discussion. This escaped the parser simply because the url is appended by "?". I even added another question mark and submitted it fine (Deleted it of course).
By becoming dependent on "IDE's" you are only making it easier for companies to control you. As developers you are important and companies want to have some control over what you do. That was Microsoft's original plan and it has worked beautifully.
They were quick to provide an OO environment where someone could create something "impressive" very fast. A little eye candy is all it takes to impress many developers and users.
And that's all she wrote. They beat everyone else to the punch. To this day, IDE's and OO programming still rule. And MS's mysterious API's are still very much a competitive advantage, tying programmers to the MS IDE and platform. They control you.
The unfortunate result of this over a long period is that today's developers are a lot less knowledgeable about how to build things from the ground up. Take away their IDE and they can't really do much.
If you want to create something truly "new" and push the envelope (think systems programming), then you need to start at a lower level than the IDE where someone else has handled the low level details for you. (Who built those objects anyway?) A recent post here on HN said that the most talented programmers are the ones who can move from different levels of abstraction effortlessly. From very high to very low and back again. The IDE keeps you in a box. One level of abstraction. Dirty low level details are scary to many developers.
IDE's are useful. They increase productivity exponentially. But if we take away your IDE and you are helpless without it, that's a problem from a progress standpoint (e.g. new systems development). Companies like MS are controlling you and controlling the rate of progress. And they have an incentive to maintain status quo. The envelope does not get pushed.
I always think of unix as the Disintegrated Development Environment, and I'm happy to keep it that way. Every time I go down the rabbit hole of trying to integrate build, debug and edit into a single tool, I eventually go back to using individual commands.
My understanding is that Emacs is not really Unix in flavor or mentality. GNU's not Unix, remember. :-)
To the best of my knowledge - i.e., I've read somewhere - Emacs is a derivative in style from Lisp Machines at the MIT Lab. It's not really a Unix program.
Unix is an aesthetic. It's squishy. Emacs is a text editor. Editing text is very much a Unix Thing. Emacs does a lot of other crap too, most of it (email, terminal emulation, IRC...) intended to replace or augment some other core Unix Thing. Is putting all those Unix Things into a single box (that isn't unix) a Unix Thing? Probably not, but most of us forgive emacs that transgression. Don't use the crap that doesn't fit your world view, and it remains a unix tool.
Emacs predates the Lisp machines, btw. The original was written (as TECO macros) on ITS. The Lisp machines came out of the same culture and thus had their own emacsen. But GNU Emacs that we are all using today was written on Unix from day one.
The author mentions that ack "allows you to use Perl-compatible regular expressions (PCRE)" in contrast to grep. I want to point out that grep does too, or at least the versions on Linux and Mac OS X, when the -E flag is used. I don't know if it actually uses the PCRE library or if it even uses the same character class shortcuts that Perl does, but it's at least modern in the sense that it uses (...) instead of \(...\) for grouping and {n,m} instead of \{n,m\} for specifying the number or range of occurrences, as well as + for {1,}, etc.
Edit: Slight fact correction. The author of this article led me to believe that ack uses Perl Compatible Regular Expressions, which is a C library that implements a regular expressions system whose pattern syntax is very similar to what's found in Perl. Now that I've read ack's website, I see that ack is written in Perl and actually uses Perl's regexps. The author must have just meant that ack's regular expressions are literally "Perl-compatible."
grep -E is just extended regex, which is also a million years old. grep -P, for some versions of gnu grep, will get you the experimental perl compatible regexes.
For a time, Unix was specifically developed as an IDE; the PWB/UNIX system was basically a version/distribution of Unix intended for development, even of programs for other machines like the IBM System/370.
Time marches on, however; and modern IDEs offer rich tools like refactoring capability, in-place documentation (IntelliSense) and fully integrated debugging tools that are a considerable evolution from what was available in the 1970s, that can only have come from having all the tools be aware of the language that's being used. From dumb, simple tools that munge streams to text to smarter, context- and semantics-aware tools that operate on program representations -- that's progress. Accordingly, Unix itself is no longer an acceptable IDE.
I like the article as I am also a command line junkie, but I have an issue with it. I might be being pedantic here, but the fundamental premise of the article is a falsehood.
UNIX is in no way, shape or form an IDE. IDE stands for Integrated Development Environment and means exactly that. All your tools under one roof.
I do not deny and in fact would also assert that the separate tool chain / everything is a stream of bytes philosophy can be used in amalgam as an incredibly powerful methodology for software development, but that doesn't make it an IDE.
I typically tweak my rc files for a particular task ($language development, packaging, communications, system configuration, etc) and spawn a screen session with my $HOME pointing at a context-specific directory. This makes everything integrate a little better around the task at hand, while still giving me the full expressibility of my shell. I don't know whether I'd quite call it "Integrated", but I find it useful.
> UNIX is in no way, shape or form an IDE. IDE stands for Integrated Development Environment and means exactly that. All your tools under one roof.
agreed. if anything, it's a UDE: Unintegrated Development Environment. which is it's strength and weakness. the initial learning curve is steeper than with an IDE, maybe, but you don't run into these painful low ceilings like with an IDE. so much synergy & integratability in the CLI paradigm. pick and choose. customizable UX, custom workflows, automation, and typically much less opaque configuration, lower idle cpu and memory use, etc.
I have cscope+vim+make/build+gdb+logging windows on auto-open for my developer desktop terms, and spend a lot of time navigating large codebases with cscope in all its incarnations. If you like this article, but haven't heard of cscope+vim, give yourself 30 minutes to check it out ..
"X as your Y" is a sign of good architecture in X.
You can consider Unix as a collection of hierarchically organized entities that can act as nouns and verbs. To develop in this system, all you need to do is to add verbs for text editing and compiling.
BeOS/Haiku has this versatile property as well. In fact, you can use BeOS as your media player/mail client with no app at all.
Python and Ruby are built with this quality. There is tremendous power in their REPL. The language is somewhat its own advanced debugger.
Smalltalk is much like Unix, with its structure of nouns and verbs and a REPL everywhere. This is precisely why the Smalltalk compiler is just another first class Smalltalk Object.
Any app like an IDE is actually something like a design pattern. It's actually a symptom of something lacking in your language/substrate. This isn't something bad or wrong, because kitchen sink architectures have their own drawbacks. It's also possible for a system to be too generalized.
Rather, the sign of something wrong (or conversely the sign of something right) is the extent to which you are building everything yourself or composing pieces that are already there. To what extent are you building together your own, and to what extent are you exploring powerful tools that are already there and putting them together to get things done?
Being able to do the latter is the definition of power in most contexts. The too much need for the former is pathological.
Unwieldy IDEs, app servers, dependency management, etc -- this is all a sign that something needs to be improved.
I'm in the process of completely switching over to the development style described in this article (I read it last weekend). I started typing a response to this and accidentally ended the first sentence with a semicolon, if that gives you any indication of where I am at in this process. I'm at a PHP/.Net shop doing LAMP development and everyone else here simply installed Ubuntu or Windows XP/7 then Eclipse, checked out the code from SVN and started working. I installed Ubuntu fairly quickly but then got fed up trying to get Eclipse and a bunch of PHP plugins working together. That was a complete waste of time in my opinion; at best I would be learning Eclipse and Ubuntu. I switched to Vim for all of my editing needs about 16 months ago when I was taking a useless Perl class, so I started using that daily at work. 8 months of 40 hour work weeks later and I'd say I'm pretty decent at it now. Two months ago I got fed up with the awful window management in Ubuntu and switched to Xmonad. Configuring my window manager by writing Haskell and recompiling it is preferable to watching some other piece of garbage break or crash constantly and wasting time moving windows around with a mouse for the rest of my life. Shortcuts didn't help; working with the default keybindings in Ubuntu for web development on a single screen hurt my hand enough to buy a different keyboard, but it was still glitchy enough to be a daily annoyance.
My development environment currently consists of Ubuntu/Arch Linux (haven't switched at work yet), Tmux, Vim, Xmonad, Urxvt and Zsh. The only sane way to start moving towards using these tools is to use one new tool at a time, see which defaults annoy you and then customize it to your workflow. I would definitely not start with anyone else's default settings (Janus for Vim or Oh-My-Zsh) unless you just want to see what these tools are capable of. Last week I completed a full productive workday without touching my mouse except to move it out of the way and over the weekend I had to work from home at this job for the first time. I had my ssh tunnels and keys setup already so it was a simple as attaching to my tmux session from work and continuing where I left off.
The reason I am going through this process is to learn more about Linux/Unix but more importantly I am sick and tired of setting up programs on computers, learning settings and modifying configurations through guis that change at the developers' whims. I don't need or want a system that anyone can use; I want a system that works the way I think with my exact hardware. The best benefit of doing all this is that I can actually learn and understand what my tools are doing and remove as many abstractions as I can handle. Most recently I learned about strace; I always wondered how people came up with answers to Linux questions about random dependencies.
Surpised tmux wasn't mentioned in the list of core tools; Author has written about it before it seems. tmux is the key to building an IDE in *nix for me.
I've been using GNU screen for years and am happy with it. A brief bit of Googling suggests to me that the main advantages of tmux over screen are that its code is designed better and that it's actively maintained and, therefore, less buggy. It also seems like its configuration is more logical. As someone who has already configured screen to my liking and who hasn't run into noticeable bugs, I don't have any real reason to make the switch if those are the only advantages. Are there others? (e.g. better features, etc.)
Yeah. POSIX shell is my IDE of choice too. So I agree with it. Although there is one exception - development in C#/.NET which is only environment in which I wouldn't code with anything else than Visual Studio. :) But maybe it's just a matter of way I was tought to use it, with all those one click - hundreds LOCs stuff. So I can't imagine coding in .NET without it.
[+] [-] ajross|13 years ago|reply
On the other, it's a giant facepalm that the simplest, best documented, most powerful development tradition of the last 40 years actually needs this treatment. That there is a whole generation of developers who come out of school thinking that "building" is the action of pressing a button in an IDE GUI (and that "writing a program" means launching a big wizard that pukes a dozen files into a new directory) is just depressing.
Oh, and get off my lawn.
[+] [-] Goladus|13 years ago|reply
Trying to read the configure scripts and Makefiles for software like Apache httpd server was overwhelming. There's obviously many man-months of work there as well as unknown styles, conventions, and tricks.
How (and why) would I go from "gcc -lexample -o program csci201.c" and maybe a simple Makefile to a 10,000-line ./configure script? I never had any idea.
[+] [-] BrainInAJar|13 years ago|reply
I use UNIX as my IDE almost exclusively. When it comes to Java however, I don't think there's any way to avoid using Eclipse or Netbeans or something. Any nontrivial Java project is going to be convoluted enough that using the traditional tools is an exercise in futility.
[+] [-] stonemetal|13 years ago|reply
[+] [-] j_baker|13 years ago|reply
Why? I mean, the fact that a newbie developer just needs to know how to press one button to build their code is actually pretty amazing. Plus, how many school projects are complex enough to require much more than that?
[+] [-] zem|13 years ago|reply
[+] [-] Peaker|13 years ago|reply
[+] [-] horsehead|13 years ago|reply
[+] [-] shanemhansen|13 years ago|reply
[+] [-] wvenable|13 years ago|reply
But you are right, if an IDE wasn't built for a task you're SOL and you can likely compose something together on the command line to solve it.
[+] [-] gjulianm|13 years ago|reply
I use Visual Studio to develop for WP7, and refactoring is even more awesome: change any name, click the little popup (non-intrusive at all) and select refactor. Done. Not only in that file, but also in your project and any other project you have opened.
I'm not trying to bash command line tools (I'd really love to know them better), but I think that there are things that are far easier with a graphical IDE.
[+] [-] einhverfr|13 years ago|reply
Sure maybe it adds a file browser or a couple of menu commands for building and running. But in terms of actual coding, VIM rules (I am sure EMACS fans feel the same way about EMACS and for similar reasons).
The selling point of an IDE is generally that it's "integrated" whatever that means. The selling point of UNIX or Linux is you can string the tools together, loosely integrated, to accomplish a better job, but it's not integrated in the same way out of the box.
I don't think there is any question that the UNIX approach leads to better productivity in my mind. The issue is that like all high productivity tools, it has a learning curve.
[+] [-] tallpapab|13 years ago|reply
[+] [-] babarock|13 years ago|reply
- bash and make are completely separate programs. As a matter of fact, I spend half of my time developing with ksh and Solaris make. The two programs you mention don't go 'hand in hand'.
- `find | xargs grep` is a terrible construct. 99% of the time (if not a lot more) you'd prefer using something like `find -exec`, I have yet to come across a version of `find` that wouldn't work that way.
My point is not to be an arrogant prick, and criticize the parent post. These kind of misconceptions usually indicate poor understanding of the larger Unix philosophy. By her own admission, my parent "just do[es]n't know enough".
I believe that in order to truly use Unix as an IDE, one has to go beyond the (arguably bad) reflexes taught by common GUI IDEs. It's not simply a matter of "What command can replace feature X from Netbeans/Eclipse/Visual Studio/...?" Modern IDEs weren't conceived with sed/awk in mind, aren't (for the most part) scriptable like most Unix shells are, and aren't sitting on top of a freaking Lisp machine like emacs is (you know the whole enlightment deal, lisp is superior, bla bla bla).
I am sounding like an evangelist, Unix tend to do that to me. I am trying to make a simple point:
It's normal to feel that something is missing if one is simply transposing her knowledge from point-and-click IDEs to the Unix shell.
(To answer your question, a combination of sed and awk does wonder to rename across the code base. And SO much more ...)
[+] [-] enduser|13 years ago|reply
[+] [-] lubutu|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] einhverfr|13 years ago|reply
[+] [-] drcube|13 years ago|reply
http://news.ycombinator.com/item?id=3594098
[+] [-] DeepDuh|13 years ago|reply
I also recommend the following talk about "subtext": http://www.subtextual.org/subtext2.html.
[+] [-] why-el|13 years ago|reply
[+] [-] goforit|13 years ago|reply
They were quick to provide an OO environment where someone could create something "impressive" very fast. A little eye candy is all it takes to impress many developers and users. And that's all she wrote. They beat everyone else to the punch. To this day, IDE's and OO programming still rule. And MS's mysterious API's are still very much a competitive advantage, tying programmers to the MS IDE and platform. They control you.
The unfortunate result of this over a long period is that today's developers are a lot less knowledgeable about how to build things from the ground up. Take away their IDE and they can't really do much.
If you want to create something truly "new" and push the envelope (think systems programming), then you need to start at a lower level than the IDE where someone else has handled the low level details for you. (Who built those objects anyway?) A recent post here on HN said that the most talented programmers are the ones who can move from different levels of abstraction effortlessly. From very high to very low and back again. The IDE keeps you in a box. One level of abstraction. Dirty low level details are scary to many developers.
IDE's are useful. They increase productivity exponentially. But if we take away your IDE and you are helpless without it, that's a problem from a progress standpoint (e.g. new systems development). Companies like MS are controlling you and controlling the rate of progress. And they have an incentive to maintain status quo. The envelope does not get pushed.
[+] [-] swdunlop|13 years ago|reply
[+] [-] pnathan|13 years ago|reply
To the best of my knowledge - i.e., I've read somewhere - Emacs is a derivative in style from Lisp Machines at the MIT Lab. It's not really a Unix program.
[+] [-] ajross|13 years ago|reply
Emacs predates the Lisp machines, btw. The original was written (as TECO macros) on ITS. The Lisp machines came out of the same culture and thus had their own emacsen. But GNU Emacs that we are all using today was written on Unix from day one.
[+] [-] ralph|13 years ago|reply
[+] [-] dsrguru|13 years ago|reply
Edit: Slight fact correction. The author of this article led me to believe that ack uses Perl Compatible Regular Expressions, which is a C library that implements a regular expressions system whose pattern syntax is very similar to what's found in Perl. Now that I've read ack's website, I see that ack is written in Perl and actually uses Perl's regexps. The author must have just meant that ack's regular expressions are literally "Perl-compatible."
[+] [-] tedunangst|13 years ago|reply
[+] [-] bitwize|13 years ago|reply
Time marches on, however; and modern IDEs offer rich tools like refactoring capability, in-place documentation (IntelliSense) and fully integrated debugging tools that are a considerable evolution from what was available in the 1970s, that can only have come from having all the tools be aware of the language that's being used. From dumb, simple tools that munge streams to text to smarter, context- and semantics-aware tools that operate on program representations -- that's progress. Accordingly, Unix itself is no longer an acceptable IDE.
[+] [-] Feoh|13 years ago|reply
UNIX is in no way, shape or form an IDE. IDE stands for Integrated Development Environment and means exactly that. All your tools under one roof.
I do not deny and in fact would also assert that the separate tool chain / everything is a stream of bytes philosophy can be used in amalgam as an incredibly powerful methodology for software development, but that doesn't make it an IDE.
[+] [-] dllthomas|13 years ago|reply
[+] [-] mkramlich|13 years ago|reply
agreed. if anything, it's a UDE: Unintegrated Development Environment. which is it's strength and weakness. the initial learning curve is steeper than with an IDE, maybe, but you don't run into these painful low ceilings like with an IDE. so much synergy & integratability in the CLI paradigm. pick and choose. customizable UX, custom workflows, automation, and typically much less opaque configuration, lower idle cpu and memory use, etc.
[+] [-] primitur|13 years ago|reply
http://cscope.sourceforge.net/cscope_vim_tutorial.html
I have cscope+vim+make/build+gdb+logging windows on auto-open for my developer desktop terms, and spend a lot of time navigating large codebases with cscope in all its incarnations. If you like this article, but haven't heard of cscope+vim, give yourself 30 minutes to check it out ..
[+] [-] soofaloofa|13 years ago|reply
[+] [-] stcredzero|13 years ago|reply
You can consider Unix as a collection of hierarchically organized entities that can act as nouns and verbs. To develop in this system, all you need to do is to add verbs for text editing and compiling.
BeOS/Haiku has this versatile property as well. In fact, you can use BeOS as your media player/mail client with no app at all.
Python and Ruby are built with this quality. There is tremendous power in their REPL. The language is somewhat its own advanced debugger.
Smalltalk is much like Unix, with its structure of nouns and verbs and a REPL everywhere. This is precisely why the Smalltalk compiler is just another first class Smalltalk Object.
Any app like an IDE is actually something like a design pattern. It's actually a symptom of something lacking in your language/substrate. This isn't something bad or wrong, because kitchen sink architectures have their own drawbacks. It's also possible for a system to be too generalized.
Rather, the sign of something wrong (or conversely the sign of something right) is the extent to which you are building everything yourself or composing pieces that are already there. To what extent are you building together your own, and to what extent are you exploring powerful tools that are already there and putting them together to get things done?
Being able to do the latter is the definition of power in most contexts. The too much need for the former is pathological.
Unwieldy IDEs, app servers, dependency management, etc -- this is all a sign that something needs to be improved.
[+] [-] pjmlp|13 years ago|reply
- replacing Foo just in specific modules/classes
- finding the call stack of a specific function/method even across closed source binaries
- provide a visual overview of modules/classes dependencies
- GUI design
- code refactoring
- debugging with hot code replacement on the fly
- browsing symbols in object files / binary modules
[+] [-] s00pcan|13 years ago|reply
My development environment currently consists of Ubuntu/Arch Linux (haven't switched at work yet), Tmux, Vim, Xmonad, Urxvt and Zsh. The only sane way to start moving towards using these tools is to use one new tool at a time, see which defaults annoy you and then customize it to your workflow. I would definitely not start with anyone else's default settings (Janus for Vim or Oh-My-Zsh) unless you just want to see what these tools are capable of. Last week I completed a full productive workday without touching my mouse except to move it out of the way and over the weekend I had to work from home at this job for the first time. I had my ssh tunnels and keys setup already so it was a simple as attaching to my tmux session from work and continuing where I left off.
The reason I am going through this process is to learn more about Linux/Unix but more importantly I am sick and tired of setting up programs on computers, learning settings and modifying configurations through guis that change at the developers' whims. I don't need or want a system that anyone can use; I want a system that works the way I think with my exact hardware. The best benefit of doing all this is that I can actually learn and understand what my tools are doing and remove as many abstractions as I can handle. Most recently I learned about strace; I always wondered how people came up with answers to Linux questions about random dependencies.
[+] [-] sequoia|13 years ago|reply
[+] [-] dsrguru|13 years ago|reply
[+] [-] JoelMcCracken|13 years ago|reply
[+] [-] krollew|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] ibisum|13 years ago|reply
[deleted]