Yeah: the idiot who frist posts something idiotic, and the idiot who then replies something obvious, (and then the idiot who responds to the idiot, pointing out what kind of idiot the idiot is)
Said 'manual tools' are typically non-interactive and hence very automatic, especially in pipelined combination.
The text editor is hardly 'plain', it's highly functional.
No... it's not.... but I really get tired of seeing people here suggest that programmers who might actually require an IDE to get their jobs done in a timely fashion are somehow less competent as programmers than
Ah, here it goes again:
people who've probably never had to work on large scale projects with schedules that aren't humanly possible to achieve if you were to just use manual tools and a plain text editor.
...did you by any chance not read the post you're replying to? Stop pretending like IDEs would naturally boost productivity, when you simply don't know both sides of the issue. I'd actually be slower using an IDE. And in no fucking way would one/ever/ need to have a grasp of the entire code base in order to work on something. When i work on a project, i work on a specific subsystem of said project. If that subsystem still consists of over 9000 lines of code, i/again/ can usually narrow down the part I need to understand to a particular feature of said subsystem, eventually arriving at a managably-sized piece of code, which i then try to understand, and edit. At the 'editing' part, i usually don't need any code-specific help from my editor anymore - what i want there, is minimizing the amount of typework I have to do.
Of course, if the code base is arbitrarily messed up and convoluted, things become different. But then again, two wrongs do not make a right. And if your coding paradigm is ``type-something-and-then-let-stupidisense-figure-it-out'', then you're generally doing it wrong.
Whether this is not the programmer's fault is irrelevant... this is how the real world of software development actually is... and a programmer who doesn't get the job done in the time that he's expected to do so is soon going to find himself unemployed. Call me picky... but I would rather be able to afford to keep a roof over my head and eat than brag about being such an awesome programmer that I don't need modern software development environments like an IDE to get a job done.
That's again all implying a programmer who doesn't use an IDE is somehow not able to get the job done in similar time. In messed-up cases that might be true, but in general it's simply wrong. Just because you can't picture it, it need not be impossible. News at 11.
Look, there are two approaches to software: the One-Tool-Does-It-All approach which we're familiar with from the Windows world. IDEs are an incarnation of this approach.
Then there's the One-Tool-For-One-Job approach, which focusses on flexibility - we know this from the unix world.
It isn't a ``heinous sin'' to think you're vastly more productive with an IDE (although most people making that claim simply do not know their unix toolbox). If you like the monolithic approach, fine.
Contrary, it's not a sin either to prefer the other (and arguably older, [hint hint, GP]) approach.
That being said, please stop tring to point out how much faster you actually are using an IDE, when in actuality you only know one side of the picture.
And yes, I used IDEs, for years, and then stopped using IDEs, years ago.
Refactoring has nothing to do with improving correctness. Besides, being faster at refactoring is an entirely unverified claim on which I call bullshit. On a broken codebase, which has lot of cross-module dependencies, global variables all over the place, shadowed by local variables here and there -- yeah, your full-parse fancy refactor thingy might get it faster. OTOH, that's not code I'd want to work with, and/or be proud of.
Any code written with a minimal reasonable amount of common sense and sanity, is quickly refactored right in the editor, for local parts, or with a combination of grep(1) find(1) and sed(1). Big deal. Learning how to use a couple unix programs sort of elimiates the need for a lot of programs previously considered indispensible.
Wouldn't I need to be a gamer for 1337ness? I'm surprised by your weird reaction -- oh wait, you're using some vi-emulation. Yeah, those kind of make me angry too, for all the features they lack.
Because that's a common use case.
OK, me editing your code it probably is.
Made me laugh, thanks.
[...] when it comes to parsing, even to related plugins, editors suck big time.
When it comes to audio playback, audio encoders suck big time. See the analogy?
@Parent's siblings: You're proving my point by pointing out how you can get kinda-sorta-vi-ish-emulation into your fancy IDEs. (I've seen a bunch of those tools and they all suck big time)
... because a *good* IDE can make you so much more productive.
I found that a good editor made me much more productive.
Yes, vim is great, yes, it can do a lot, but it still does not know what you are writing there.
I'd argue that it's not the job of my tools to understand my code for me. The coder is the guy to have to understand the code.
That being said, I wouldn't even/want/ to have my text editor understand my code for me, because it's a text editor.
My IDE does and thanks to that I can refactor stuff in seconds that took minutes earlier (or maybe even hours) and I make less mistakes doing so. Having to spend less time on boring tasks makes the whole job of programming something so much more enjoyable!
Oh wow. Yeah, what's having to use a notepad-style integrated text editor when you can/refactor/ your code with just one click! Convinced me, will purchase.
You need a good IDE though with a good code model, so that it actually understands the code you are writing.
Redundant much?
Many of the free IDEs do not have that, so those are a total waste of time.
As is any other IDE
KDevelop, Eclipse and Qt Creator all have a code model though and do support you with quite a few refactoring operations (like move code around, rename variables and classes, etc.).
Refactoring, again. Is there any other reason to use an IDE or is it all about refactoring?
FWIW, i found that a tiling window manager like i3 and some xterms make up for a way superior development environment than any IDE i've seen so far (and I have seen a few).
Ever considered that an interface which is by design keyboard-driven is infinitely superior to a mouse-focussed GUI which also happens to offer some keyboard shortcuts? It's just not comparable.
For instance, what shortcut would you use for even something utterly trivial as 'delete N lines downwards'? Whatever shortcut that might be, you'd very likely end up hitting the same key combo N times.
#!/bin/sh
# script: safepassword
# this script depends on sha512sum
if [ $# -ne 2 ]
then
cat <<-END >&2
usage: safepassword constant_key password_
where constant_key is a string of printable non-whitespace characters,
and password_purpose is a memorable string related to the purpose of
the password, e.g. a website address and year. Since the script removes
any characters outside 0-9 a-z A-Z it is possible that the password
could be too short in some cases. END
else
echo -n "$1-$2" | sha512sum | xxd -r -p | sed 's/[^0-9a-zA-Z ]//g'
echo
fi
Yeah: the idiot who frist posts something idiotic, and the idiot who then replies something obvious, (and then the idiot who responds to the idiot, pointing out what kind of idiot the idiot is)
manual tools and a plain text editor.
Said 'manual tools' are typically non-interactive and hence very automatic, especially in pipelined combination.
The text editor is hardly 'plain', it's highly functional.
You seem to know your stuff very well.
No... it's not.... but I really get tired of seeing people here suggest that programmers who might actually require an IDE to get their jobs done in a timely fashion are somehow less competent as programmers than
Ah, here it goes again:
people who've probably never had to work on large scale projects with schedules that aren't humanly possible to achieve if you were to just use manual tools and a plain text editor.
...did you by any chance not read the post you're replying to? Stop pretending like IDEs would naturally boost productivity, when you simply don't know both sides of the issue. I'd actually be slower using an IDE. And in no fucking way would one /ever/ need to have a grasp of the entire code base in order to work on something. When i work on a project, i work on a specific subsystem of said project. If that subsystem still consists of over 9000 lines of code, i /again/ can usually narrow down the part I need to understand to a particular feature of said subsystem, eventually arriving at a managably-sized piece of code, which i then try to understand, and edit. At the 'editing' part, i usually don't need any code-specific help from my editor anymore - what i want there, is minimizing the amount of typework I have to do.
Of course, if the code base is arbitrarily messed up and convoluted, things become different. But then again, two wrongs do not make a right.
And if your coding paradigm is ``type-something-and-then-let-stupidisense-figure-it-out'', then you're generally doing it wrong.
Whether this is not the programmer's fault is irrelevant... this is how the real world of software development actually is... and a programmer who doesn't get the job done in the time that he's expected to do so is soon going to find himself unemployed. Call me picky... but I would rather be able to afford to keep a roof over my head and eat than brag about being such an awesome programmer that I don't need modern software development environments like an IDE to get a job done.
That's again all implying a programmer who doesn't use an IDE is somehow not able to get the job done in similar time. In messed-up cases that might be true, but in general it's simply wrong. Just because you can't picture it, it need not be impossible. News at 11.
Look, there are two approaches to software: the One-Tool-Does-It-All approach which we're familiar with from the Windows world. IDEs are an incarnation of this approach.
Then there's the One-Tool-For-One-Job approach, which focusses on flexibility - we know this from the unix world.
It isn't a ``heinous sin'' to think you're vastly more productive with an IDE (although most people making that claim simply do not know their unix toolbox). If you like the monolithic approach, fine.
Contrary, it's not a sin either to prefer the other (and arguably older, [hint hint, GP]) approach.
That being said, please stop tring to point out how much faster you actually are using an IDE, when in actuality you only know one side of the picture.
And yes, I used IDEs, for years, and then stopped using IDEs, years ago.
Refactoring has nothing to do with improving correctness. Besides, being faster at refactoring is an entirely unverified claim on which I call bullshit.
On a broken codebase, which has lot of cross-module dependencies, global variables all over the place, shadowed by local variables here and there -- yeah, your full-parse fancy refactor thingy might get it faster. OTOH, that's not code I'd want to work with, and/or be proud of.
Any code written with a minimal reasonable amount of common sense and sanity, is quickly refactored right in the editor, for local parts, or with a combination of grep(1) find(1) and sed(1).
Big deal.
Learning how to use a couple unix programs sort of elimiates the need for a lot of programs previously considered indispensible.
Wouldn't I need to be a gamer for 1337ness?
I'm surprised by your weird reaction -- oh wait, you're using some vi-emulation. Yeah, those kind of make me angry too, for all the features they lack.
Because that's a common use case. OK, me editing your code it probably is.
Made me laugh, thanks.
[...] when it comes to parsing, even to related plugins, editors suck big time.
When it comes to audio playback, audio encoders suck big time. See the analogy?
@Parent's siblings: You're proving my point by pointing out how you can get kinda-sorta-vi-ish-emulation into your fancy IDEs. (I've seen a bunch of those tools and they all suck big time)
... because a *good* IDE can make you so much more productive.
I found that a good editor made me much more productive.
Yes, vim is great, yes, it can do a lot, but it still does not know what you are writing there.
I'd argue that it's not the job of my tools to understand my code for me. The coder is the guy to have to understand the code. /want/ to have my text editor understand my code for me, because it's a text editor.
That being said, I wouldn't even
My IDE does and thanks to that I can refactor stuff in seconds that took minutes earlier (or maybe even hours) and I make less mistakes doing so. Having to spend less time on boring tasks makes the whole job of programming something so much more enjoyable!
Oh wow. Yeah, what's having to use a notepad-style integrated text editor when you can /refactor/ your code with just one click! Convinced me, will purchase.
You need a good IDE though with a good code model, so that it actually understands the code you are writing.
Redundant much?
Many of the free IDEs do not have that, so those are a total waste of time.
As is any other IDE
KDevelop, Eclipse and Qt Creator all have a code model though and do support you with quite a few refactoring operations (like move code around, rename variables and classes, etc.).
Refactoring, again. Is there any other reason to use an IDE or is it all about refactoring?
FWIW, i found that a tiling window manager like i3 and some xterms make up for a way superior development environment than any IDE i've seen so far (and I have seen a few).
Ever considered that an interface which is by design keyboard-driven is infinitely superior to a mouse-focussed GUI which also happens to offer some keyboard shortcuts? It's just not comparable.
For instance, what shortcut would you use for even something utterly trivial as 'delete N lines downwards'? Whatever shortcut that might be, you'd very likely end up hitting the same key combo N times.
(Note that this is a rhetorical question. Please spare me the details on how you can't develop without pushing around your mouse)
...what /for/?
You for one, are doing it wrong.
Want to do a crazy program you can't write on modern computers?
What?
Simply loop through a sequence of poking two random numbers, and incrementing a number that you print.
What?
Every time, the system will do different things.
What ?
If you did this on a modern computer, eventually it'd corrupt system files and the thing wouldn't boot.
WHAT?
It makes you wonder why modern OSes aren't hardened with the theory: No matter what the user does, allow the computer to boot up safely next time.
You're an idiot.
you're 73% funny
I don't speak English you insensitive clod!
that 87% of all studies are completely made up.
No.
Protip: Select "Plain Old Text" where it currently reads "HTML Formatted"
did you died?
... and why is he annoyed when someone tells someone else about him?
Protip: The device is not supposed to trigger on mainstream music.
(That being said, you should still refrain from touching its operational end.)
#!/bin/sh
# script: safepassword
# this script depends on sha512sum
if [ $# -ne 2 ]
then
cat <<-END >&2
usage: safepassword constant_key password_
where constant_key is a string of printable non-whitespace characters,
and password_purpose is a memorable string related to the purpose of
the password, e.g. a website address and year. Since the script removes
any characters outside 0-9 a-z A-Z it is possible that the password
could be too short in some cases.
END
else
echo -n "$1-$2" | sha512sum | xxd -r -p | sed 's/[^0-9a-zA-Z ]//g'
echo
fi
FTFY...
1. Make freshwater river
2. Make saltwater river
3. Connect at both ends
4. ???
5. Infinite Energy
Users.each{|user|
That made my eye twitch. Gross syntax.
I can only agree. I have several friends who really know their C# -- and they drive their taxis so well!