Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm using the Qt Creator IDE right now, in Linux of all places.

The Desktop GUI I'm making involves about twenty libraries, multiple threads and other complexities.

I could make my job even more complex by diving in and learning a command-line way to do everything. But it seems to me, my personal approach is, I move ahead by dealing with the necessary complexity and letting the unnecessary complexity fall away.

I mean, I'm sure there a way use ls with wildcards in a way that doesn't puke all subdirectories out at you when you're trying to find a single file in a large directory. But the fact that ls does this by default seems like strong evidence that the interface wants you to remember random bs - indeed, I've read stuff here where people were saying essentially "vi is good because it makes me remember arbitrary commands, strengths your brain". It might even be true that it strengths your brain but I think only a subset of even geeks want to relate to their computers like this and this subset isn't the same as geeks who can create useful and powerful programs or the most productive subset.

Also, I don't see any inherently more powerful tools here. Qt Creator can show me the meaningful references to variable foo, excluding comment "foo". I can't see grep doing that (even though I use grep for some thing but I still memorize ten cli options). All the tools are pretty Turing complete if you dig so it's hard to claim one thing is more powerful than another.



First off: clearly you're right. IDE's are very large, featureful software and there are lots of specific tasks they accelerate that you won't find addressed in the common CLI workflow. Finding "references to foo" is a good example.

But here's some stuff Qt Creator can't do (or rather, provides no particular support for -- you can always use it as a text editor, of course): iOS apps; Android apps; sending email automatically; kernel drivers; languages other than C++ or Javascript: Scala, Haskell, TCL, C#, sh, perl, prolog, lisp...; build and deploy a node.js app; fire up an AWS instance; build a binary for an AVR microcontroller and download it to a device; Verilog or VHDL editing/synthesis/verification.

Obviously I could go on and on, but you get the point. The command line environment? Yeah. It "does" all that stuff. And it does it in the same way. A Makefile for your VHDL project is going to look like a Makefile for your web app. The build scripts for your machine learning rig and your AVR hackery work the same way. You write your email in the same editor you use to write your C++ and CoffeeScript (and that you used 20 years ago to write your TCL!).

So sure: if you want to spend your career searching for "foo" in your Qt C++/QML projects, Qt Creator is a great choice. And the next environment you work in will have a new tool, that does all the same boring stuff in mostly the same ways, and you'll need to learn it again. Pick up the command line and get better at it and you'll find you've opened up a much bigger door (and you won't need to learn to use a new editor every year, to boot).

Is it clear now why there are some of us (with decades of make and shell and ssh in our toolbelts) who sit here and scratch our heads at the perpetuation of this nonsense?


> Is it clear now why there are some of us (with decades of make and shell and ssh in our toolbelts) who sit here and scratch our heads at the perpetuation of this nonsense?

It's no more clear than it was before--that is to say, perfectly so. But here's one for you, in turn: I'm glad that it works for you and that you like it, but if you want to insist it's objectively superior and I don't know what's better for me (which is what you've been doing throughout this thread), I cordially invite you to go fuck yourself. Impolite of me, sure, but telling you to go fuck yourself is considerably less impolite than patronizing people who decide they don't value working in the same way you do. I've been where you say to be, I've done what you say to do, and I got the T-shirt that you're rocking out in. I put it in a drawer because I think it wears poorly.

I have plenty of experience with "make, shell, and ssh"--I'm neither new to nor afraid of working in shells. Doesn't mean I want that to be my primary work environment and certainly doesn't mean I'm either ignorant or wrong for disliking it. For me, a phrase which I will italicize a few more times because you seem unable to internalize this, the UX of the command line abjectly sucks for tasks beyond basic file manipulation and quick text editing. It sucks! For me. I don't care about its hallowed consistency when it makes me feel like shit to be using it all day and makes me feel like I'm wasting my time. Learning new tools is, for me, a smaller cost than hating what I do. I'd rather go learn a new tool, one that's specialized to its use case, because in every case I've encountered it is both a more productive and more enjoyable experience. If I'm not going to value doing my job in an enjoyable fashion, I might as well go be a plumber.

I'm more than happy to use the command line to handle deployment tasks and other automation, but for actually creating things, writing code and doing development work? I'd rather have a tooth pulled than work in vim all day. But I recognize that that's the case for me. Your decisions to use those tools are right for you but not for me are your decisions--if they make you happy, awesome! But your patronizing "what you do is nonsense" crap (and your consistent implication that not adopting your methods is borne out of ignorance rather than experience) leads me to invite you to GFY.

Preferring consistent tools to specific tools for different tasks is not better; it is preference. And, quite literally, nothing more.


I stare at Vim all day long and I can say that I don't give a shit what tools you use. Use whatever works best with how you think. Personally, I don't need to write a text editor because a group of people who more-or-less think about how to use computers the exact same way as me already did that.

I don't know why you took the parent post so personally; they never attempted to convince you that the command line is superior all the time for everyone. I can relate to it already. I saw a post on here a few days ago about shortcuts for some random new-ish editor (Sublime text 2?) listing awesome shortcuts that people should use. So what? None of that can compare to what is possible in Vim and it never will. I'm sure it's helpful for those who use that tool, but sometime soon there will be some other new tool that replaces it as the hot new editor for language x and those people will have to relearn it when they switch tools. However, that new tool will still use <ctrl-g> to find by line number.

Learning new tools on Linux is as easy as reading the man page or reading online and failing that I would dive into the source code. For example, I learned how to use rsync last night, but only enough to do what I was trying to do. Luckily, that knowledge will build as I require new uses for it. What makes this all worthwhile is that I can now make my computer do whatever I want and I am not limited to what others have built for a specific use case because these tools can handle almost anything.


> I don't know why you took the parent post so personally; they never attempted to convince you that the command line is superior all the time for everyone.

Characterizing a well-reasoned decision not to use the command line and command line tools for everything as "nonsense" certainly is implicitly placing your chosen tool stack as objectively superior. It isn't.

The rest of your post is more of the same--I'm glad it works for you (and for text editing I use MacVim quite often, but not for development because for that task it sucks for me) and its reasons are great for you, but it is not objectively superior. Which is why I responded to the post to which I responded in the first place--because it was the sort of sneering arrogance that's so common in these parts, where my way is the best way. It is the best for you, and I'm happy that you enjoy it, but taking the tribal rock-throwing ("what you have chosen to do is 'nonsense'") attitude that ajross did is stupid.


But, but, UNIX command line tools are tools :D. If you enjoy learning new tools why don't you learn a set of tools that is applicable to any future task/programming language you will encounter?


I don't enjoy learning new tools. I enjoy the user experience of using the right tool for the job more than I do using the same tools for every job.

For example: I use MacVim and Textmate for text editing (writing markdown files, etc.) because they're good at it. And that's about where it ends, for me; I would under no circumstances use it to write more code, than a one-off Python script because I find it displeasing to do. I feel annoyed and angry because writing code in it is, for me, a slog; I consider ctags basically defective and they're not as good as, say, IDEA's Python (or Java, or Scala) support (or Visual Studio's for C# or VS's and Xcode's for C++).

Similarly, and heading back towards the command-line realm: while this thread is full of people extolling the virtues of make (and my eyes made a credible attempt to roll out of my head at the idea, because make is one of the build tools I swear at most often at work...), it would be utterly stupid of me to use make for most of my personal projects because xbuild (for C#) and Maven (for Java) exist--but, oh the horror, they're specialized to their task, what if I want to flip waffles instead? And to that I respond, I don't care about using xbuild or Maven to flip waffles, because their job is not to flip waffles but instead to build C# and Java code. If I need to write a platform-independent build script for C or C++, sure, I'll use make (although today I'm more likely to use cmake), but that doesn't make it a wonderflonium-packed delight for everything else under the sun. I know this from personal experience; I deal with a make-powered Java app with makefiles best termed "monstrous" and if I could turn back the clock and make it a Maven application we'd have about a tenth of the headaches that we get from the current system. Because it's made for the job.

I would rather adapt to tools better suited to a given task than use consistent tools across all problem sets. I don't find picking up new tools to be daunting or particularly time consuming (I picked up IDEA in about two hours, despite it being markedly different in behavior than previous IDEs I'd used, and I'm significantly more productive) and I don't find value in the "elegance" of bolting 30,000 things into vim to make it almost as good as my IDE was, for me, a decade ago.

But what I have said above, if you listen to ajross, is head-scratching nonsense. Which is patronizing and insulting to people who've decided that their priorities aren't his. Such was the attitude to which I replied.


Very well written post.


This is one of those cases where you should have calmed down before typing.


Ah, the "which way is the logical way" stuff is such an arbitrary but yet so weirdly satisfying...

I could to write emails with vi and I could learn to write python extensions for Qt Creator to do just about anything also. I could add an email-sending make step to my project if I happen to want send emails when I checked changes into git. I don't know which one is better and I don't do either right now because I don't have to.

As far as doing things "the same way" goes, the same way as what? I've actually done lets of command-lining in my time. When I need to formulate a twenty argument command, I usually edit it in a text file and paste it to the prompt. And the thing is, the argument syntax of shell commands isn't consistent. The only unifying factor is the various pipes but it's hardly a panacea. I mean, fricken grep only searches directories recursively for a pure wildcard search (just "*"). You can pipe the results of this search to a further search for, say. ".cpp" but if you've got lots of non "cpp" files that happen to have the "cpp" string next to the string you want in them, you're hosed. I'm sure someone has some other trick for this somewhere. But the situation seems to boil down to "you can do anything if you take the time to learn everything" - I mentioned you could write custom IDE extensions right?


The best of all possible worlds?

emacs.




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

Search: