17 byte allocation
-
@blakeyrat said:
@morbiuswilters said:
I saw. I'm trying to figure out if GIMP will let me make a less-shitty animated GIF or if I should just say it's a statement about FOSS image software.
I gave you one! Just download and use it! Or just don't download it and link to my server! Or something.
I'll be damned. I only saw the PM as an email and apparently CS doesn't embed images so I had no idea you'd sent one. I put it on my server. Thanks!
-
Thank you, now I can watch the neck-cock-stroking without getting bugged by how poorly the GIF was made!
-
AAAAAAAAAAAAAAAAAAAAAAAAAAAAA MAKE THE FLASHING COLORS GO AWAY
@blakeyrat said:Okay!
-
@blakeyrat said:
Filed under: psychological issues
The really disturbing part is that it's from a fictional kids cartoon which itself was part of a kids movie. And this section of the cartoon happened right after the guy who is getting his neck stroked saw a pretty cavewoman, making it the most overtly-sexual thing I've seen in a movie aimed at kids since that scene in The Little Mermaid where Ariel is getting married and the priest pulls out a gun and shoots Prince Eric in the head and then they all run a train on Ariel.
-
Could you fix your signature having a margin? On my screen it looks like this:
@morbiuswilters said:
My Signature! Get your own!
-
@blakeyrat said:
GDB doesn't even have a GUI. How can anybody use a debugger without a GUI? Fail.
Those guys who use WinDBG (which actually is pretty much the only debugger in Windows that supports debugging 64 bit assembly). Many tools use those in the background as server and provide their own GUIs for them (like IDA or Eclipse).
-
@morbiuswilters said:
I remember hearing once "The music you'll end up listening to for life is what was on the radio when you were losing your virginity."
I don't know any music that is a constant barrage of extatic female screams.
-
@PJH said:
she
You're tapping into the "whiny bitch woman" stereotype?
Come on, you're better than that!
-
@blakeyrat said:
Thank you, now I can watch the neck-cock-stroking without getting bugged by how poorly the GIF was made!
HOLD UP— YOU GAVE HIM THAT IMAGE?
YOU DISGUSTING INDIVIDUAL.
-
@Buzer said:
@blakeyrat said:
GDB doesn't even have a GUI. How can anybody use a debugger without a GUI? Fail.
Those guys who use WinDBG (which actually is pretty much the only debugger in Windows that supports debugging 64 bit assembly). Many tools use those in the background as server and provide their own GUIs for them (like IDA or Eclipse).
Debugging assembly is a very low-level task, for which a low-level tool like WinDBG is suited. Debugging C/C++ is a far higher-level task, for which a low-level tool like gdb is emphatically NOT suited. And yes, I have used both tools.
-
@dhromed said:
@morbiuswilters said:
I remember hearing once "The music you'll end up listening to for life is what was on the radio when you were losing your virginity."
I don't know any music that is a constant barrage of extatic female screams.
You were listening to women screaming on the radio while you lost your virginity? That sounds like a disappointing experience.
-
@Buzer said:
Those guys who use WinDBG (which actually is pretty much the only debugger in Windows that supports debugging 64 bit assembly).
I don't understand your argument here exactly. I guess you're saying that because Microsoft has a CLI debugger, therefore that's all everybody else should have? Even though MS also ships excellent graphical debuggers? Or are you just going off on something utterly irrelevant to the discussion? Help me out here.
@Buzer said:
Many tools use those in the background as server and provide their own GUIs for them (like IDA or Eclipse).
Yeah a computer talking to a human interface, AWESOME IDEA! That would never lead to buggy or stagnant software. Why, just look at the Linux ecosystem! Vibrant as the day is long!
Hey look at this:
Microsoft Basic 1.0 for Mac, circa 1985. The cool hand is the instruction pointer. It has the variable inspection window open. AMAZING NEW SCI-FI TECHNOLOGY! Someone call up the Ruby guys!
Of course thinking back to the "iOS has no JavaScript debugger" thread from ages back, the reason these tools don't have decent debuggers is that no "software developers" (to use the term lightly) use or value debuggers. Or in the case of iOS web developers, even know what a debugger is. Why is this? Because they're walking, talking, WTF factories is the only reason I can think of.
-
@blakeyrat said:
How can anybody use a debugger without a GUI?
Some people know how to read and use the keyboard.
-
@boomzilla said:
@blakeyrat said:
How can anybody use a debugger without a GUI?
Some people know how to read and use the keyboard.
I'm not sure what blakey thinks a debugger is for. It's obviously not looking at the values of variables at runtime, setting breakpoints, getting backtraces, or any of the other things a debugger is traditionally used for. Here's a quick example. The things I typed are in bold.
Here's a simple program that a VB "programmer" might write when trying to print the program name in C:
#include <stdio.h>
int main(int argc, char **argv) {
printf("%s\n", argv[1]);
return 0;
}
Anyone who has used a language other than VB knows this is wrong. Array indices start at 0, not 1. Here's my theoretical debugging session:ben@loads blakeyc$ gdb ./bug GNU gdb (GDB) Fedora (7.5.1-37.fc18) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/ben/misc/blakeyc/bug...done. (gdb) start Temporary breakpoint 1 at 0x40053b: file bug.c, line 4. Starting program: /home/ben/misc/blakeyc/bug Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde58) at bug.c:4 4 printf("%s\n", argv[1]); (gdb) step _IO_puts (str=0x0) at ioputs.c:34 34 { (gdb) 36 _IO_size_t len = strlen (str); (gdb) __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:25 25 xor %rax, %rax (gdb) 26 mov %edi, %ecx (gdb) 27 and $0x3f, %ecx (gdb) 28 pxor %xmm0, %xmm0 (gdb) 29 cmp $0x30, %ecx (gdb) 30 ja L(next) (gdb) 31 movdqu (%rdi), %xmm1 (gdb) Program received signal SIGSEGV, Segmentation fault. __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31 31 movdqu (%rdi), %xmm1 (gdb) bt #0 __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31 #1 0x0000003bd726d54c in _IO_puts (str=0x0) at ioputs.c:36 #2 0x000000000040054e in main (argc=1, argv=0x7fffffffde58) at bug.c:4 (gdb) up #1 0x0000003bd726d54c in _IO_puts (str=0x0) at ioputs.c:36 36 _IO_size_t len = strlen (str); (gdb) #2 0x000000000040054e in main (argc=1, argv=0x7fffffffde58) at bug.c:4 4 printf("%s\n", argv[1]); (gdb) p argv $1 = (char **) 0x7fffffffde58 (gdb) p argv[1] $2 = 0x0 (gdb) p argv[0] $3 = 0x7fffffffe1cd "/home/ben/misc/blakeyc/bug" (gdb) quit A debugging session is active. Inferior 1 [process 27529] will be killed. Quit anyway? (y or n) y
-
@boomzilla said:
@blakeyrat said:
How can anybody use a debugger without a GUI?
Some people know how to read and use the keyboard.
I'm pretty sure that blakeys point is that WHY would anyone use a debugger without a GUI, when such things exist, and they provide an inherently quicker interface between the stuff thats being debugged, and the person doing the debugging.
When one tool lets you see your call stack, watches/autos, breakpoints, source code, all breakpoints, blah, blah, blah etc., SIMULTANEOUSLY, and even provides both a "Command window" and "Immediate window" that essentially provide basic CLI functionality on top of all that good stuff....
...then WHY would you chose not to have it?
There are only 3 logical reasons (all of which categorize you as a noob):
You enjoy developing software more slowly so you can bill your clients for more hours, which is its own WTF.
The language/platform you're developing in/for does not have such tools available (or you cannot afford them), also a WTF.
You learned how to do it the hard way about 30 years ago, and (convinced as you are of your general 1337ness) haven't since bothered to find out that you're doing it wrong.
-
@eViLegion said:
I'm pretty sure that blakeys point is that WHY would anyone use a debugger without a GUI,
Your post is 100% right, but there's also a "how" factor... if you're debugging a console app, how do you use a debugger in the same console? Like... I suppose it just maps some special key combination to "pause"? But you can't see the program output while you're debugging or... how would that work? (Apparently Ben L dodged that bullet in his example by picking an app with a breakpoint already defined.)
I could see using a CLI debugger for a service or GUI app, but how could it possibly work with another CLI app? Sounds like it would be painful as hell, at best.
-
@blakeyrat said:
(Apparently Ben L dodged that bullet in his example by picking an app with a breakpoint already defined.)
That'd be any program with a main method, sir.
-
@eViLegion said:
When one tool lets you see your call stack, watches/autos, breakpoints, source code, all breakpoints, blah, blah, blah etc., SIMULTANEOUSLY, and even provides both a "Command window" and "Immediate window" that essentially provide basic CLI functionality on top of all that good stuff....
...then WHY would you chose not to have it?I use both CLI debuggers and IDE debuggers. Neither seems significantly more or less productive to me. Like any CLI tool, the interface isn't as obvious as randomly clicking or looking for tooltips. With a CLI, I don't have to have all that stuff up if I don't need it. Why would I choose to have all the stuff visible then I don't need it?
Of course, I seem to live in the debugger a lot less than the way blakeyrat describes his development experience. I rarely step through lines of code. In languages that give stack traces (e.g., java) I'm usually just looking at variable values at the time of crash. In languages like C or C++, I'm looking for the point of the crash, plus the variable values. There's not a whole lot of value added by having everything wrapped in a GUI.Any console apps I work on are typically not curses style things, so I can't say how people work on those. I assume they fire up the application and then attach a debugger from some other terminal session, just like the GUI debugger would do.
I know that people like blakeyrat are convinced that a GUI is always and everywhere faster and more productive than any CLI, but that doesn't make it true.
-
@eViLegion said:
You learned how to do it the hard way about 30 years ago, and (convinced as you are of your general 1337ness) haven't since bothered to find out that you're doing it wrong.
Ah, the sunk cost fallacy. See also: vi, emacs
While I do believe that the CLI can be better than the GUI for certain tasks (gasp!), debugging is not one of them.
-
@blakeyrat said:
@eViLegion said:
I'm pretty sure that blakeys point is that WHY would anyone use a debugger without a GUI,
Your post is 100% right, but there's also a "how" factor... if you're debugging a console app, how do you use a debugger in the same console? Like... I suppose it just maps some special key combination to "pause"? But you can't see the program output while you're debugging or... how would that work? (Apparently Ben L dodged that bullet in his example by picking an app with a breakpoint already defined.)
I could see using a CLI debugger for a service or GUI app, but how could it possibly work with another CLI app? Sounds like it would be painful as hell, at best.
Yeah...
I can imagine, if it really is the only tool available for the platform you're using, that its fair enough to use some horrible command line debugger... but only as a last resort... if I really had to do it, then yeah, I could do it... but I wouldn't be even slightly happy about it, and would certainly voice my concerns to my manager in the strongest possible terms.
I guess it harks back to the old days when people ran a secondary monitor using a Hercules graphics card, on the basis that the Hercules operated in a different way (I think it mapped its video memory to a different address range from a regular IBM compatible CGA card), so you could have debugging software which exploited that, and output its info to the Hercules monitor, while the software you're debugging had its output on the primary monitor. Back in the day, this would have been a paragon of convenience.
These days, of course, the fact that dual-head cards, and window-based operating systems exist has made that whole method obsolete 10 times over.
-
@dhromed said:
@morbiuswilters said:
I remember hearing once "The music you'll end up listening to for life is what was on the radio when you were losing your virginity."
I don't know any music that is a constant barrage of extatic female screams.
Oh, he wanted to listen to Cher, huh?
-
@eViLegion said:
There are only 3 logical reasons (all of which categorize you as a noob):
You enjoy developing software more slowly so you can bill your clients for more hours, which is its own WTF.
The language/platform you're developing in/for does not have such tools available (or you cannot afford them), also a WTF.
You learned how to do it the hard way about 30 years ago, and (convinced as you are of your general 1337ness) haven't since bothered to find out that you're doing it wrong.You missed the 4th, and most common, reason. Most of these people did not learn to debug 30 years ago--if they did, hardly anybody'd still be doing it. No, these are young folks who are learning it this way. Why? I've said it before, but let me give you the formalized version:
Morbs' WTF Axiom MCVI: Many developers will persist in using inferior tools simply because they think the extra work makes them smarter. It's the same reason a lot of people use FOSS: the thought is that if it's harder to use, that must mean the user is more of a badass expert. This is why they seem to hate M$ with a passion normal people tend to reserve for serial killers--it's all about going against the mainstream, and showing how much smarter they are than all those people who beat them up in high school. Unlike most people, who choose tools based on what is useful and economical, these sad souls have their entire ego wrapped up in which OS they use, which language they program in, because to them it's what makes them better than other people.
-
-
@morbiuswilters said:
Morbs' WTF Axiom MCVI: Many developers will persist in using inferior tools [...] FOSS [...] Unlike most people, who choose tools based on what is useful and economical [...]
Quality has nothing to do with whether the software is free.The simple fact is that some people are more comfortable doing things one way, and other people like to do the same thing a different way. Any measure of "how good this program is" beyond programs that obviously don't do what they advertise is completely subjective. I'm personally more comfortable in a terminal when I write code and in a GUI web browser when I post on TDWTF. I have tried MSVC, but it just didn't work for me. I'm not saying it's a bad program. I'm not saying you shouldn't use it. I'm saying I personally don't like it. That is all I am saying.
A lot of the arguments around here stem from communication failures, either on the sending or receiving end. This might occur because the layout of forum discussions is nonlinear. In real life conversations, the topic moves on. In forum conversations, a topic can be revisited in its previous state years after it was last discussed and everyone can just read to know what was happening.
There are things that CLI applications are best for: Compiling code is one. Even your beloved Visual Studio uses a CLI to compile its code. Another example is finding the latency between you and a remote server. It's much easier to run
ping www.google.comthan it is to open Microsoft Visual Latency Tester 2019 and select a server through some convoluted "wizard".GUIs are better at some things as well. Video games are the most obvious example. Half-Life 2 wouldn't be nearly as fun if it was just a prompt where you would type
] shoot gun at combineAnother example of a GUI-specific task is web browsing. If you browse using telnet, you'll never see many of the things that make the web the web.Some kinds of programs can be either GUI or CLI. For example, an IRC client has no flashy graphics. It can be a GUI application for people who like clicking on buttons or a CLI application for people who are good at remembering key combinations. A system monitor can be a GUI or a CLI without one losing any important features the other one has.
Text editing and debugging tool preferences vary. Deal with it. If you don't like something, that doesn't mean it's a statically Bad Thing. It just means that your preference is for a different thing. Other people can use the things that you don't like or aren't good at using and get to the same result with the same amount of work. The editor doesn't determine how good the code is. That lies with the programmer.
-
When you were in school, they taught you "everyone is a winner", didn't they?
-
@Ben L. said:
GUIs are better at some things as well. Video games are the most obvious example. Half-Life 2 wouldn't be nearly as fun if it was just a prompt where you would type
] shoot gun at combineI don't know, I beat Nethack a little while back, and that was intense.
@Nethack said:
Aug-29 2012
Goodbye Thelis the Demigod...
You went to your reward with 5302516 points,
Magicbane (worth 3500 zorkmids and 8750 points)
The Master Key of Thievery (worth 3500 zorkmids and 8750 points)
The Bell of Opening (worth 5000 zorkmids and 12500 points)
The Candelabrum of Invocation (worth 5000 zorkmids and 12500 points)
The Book of the Dead (worth 10000 zorkmids and 25000 points)
The Eye of the Aethiopica (worth 4000 zorkmids and 10000 points)
21 amber stones (worth 21000 zorkmids),
17 jet stones (worth 14450 zorkmids),
14 rubies (worth 49000 zorkmids),
14 sapphires (worth 42000 zorkmids),
13 topaz stones (worth 11700 zorkmids),
12 emeralds (worth 30000 zorkmids),
11 obsidian stones (worth 2200 zorkmids),
10 jasper stones (worth 5000 zorkmids),
9 agate stones (worth 1800 zorkmids),
8 garnet stones (worth 5600 zorkmids),
7 turquoise stones (worth 14000 zorkmids),
6 opals (worth 4800 zorkmids),
5 jacinth stones (worth 16250 zorkmids),
5 aquamarine stones (worth 7500 zorkmids),
5 fluorite stones (worth 2000 zorkmids),
4 black opals (worth 10000 zorkmids),
4 chrysoberyl stones (worth 2800 zorkmids),
2 diamonds (worth 8000 zorkmids),
2 citrine stones (worth 3000 zorkmids),
2 amethyst stones (worth 1200 zorkmids),
1 dilithium crystal (worth 4500 zorkmids),
1 jade stone (worth 300 zorkmids),
4 amulets of life saving (worth 600 zorkmids),
and 28839 pieces of gold, after 76686 moves.
You were level 23 with a maximum of 413 hit points when you ascended.
-
@boomzilla said:
@eViLegion said:
When one tool lets you see your call stack, watches/autos, breakpoints, source code, all breakpoints, blah, blah, blah etc., SIMULTANEOUSLY, and even provides both a "Command window" and "Immediate window" that essentially provide basic CLI functionality on top of all that good stuff....
...then WHY would you chose not to have it?I use both CLI debuggers and IDE debuggers. Neither seems significantly more or less productive to me. Like any CLI tool, the interface isn't as obvious as randomly clicking or looking for tooltips. With a CLI, I don't have to have all that stuff up if I don't need it. Why would I choose to have all the stuff visible then I don't need it?
Of course, I seem to live in the debugger a lot less than the way blakeyrat describes his development experience. I rarely step through lines of code. In languages that give stack traces (e.g., java) I'm usually just looking at variable values at the time of crash. In languages like C or C++, I'm looking for the point of the crash, plus the variable values. There's not a whole lot of value added by having everything wrapped in a GUI.Any console apps I work on are typically not curses style things, so I can't say how people work on those. I assume they fire up the application and then attach a debugger from some other terminal session, just like the GUI debugger would do.
I know that people like blakeyrat are convinced that a GUI is always and everywhere faster and more productive than any CLI, but that doesn't make it true.
I don't think you're using your debugger effectively. It's not just there for crashes. I personally write a lot of original code while stopped at a breakpoint.
And I'm a low-level guy... but that Windbag thing both sucks and blows. I'm pretty sure I already deconstructed it in another post. Yes, there are things nothing else can do; I would therefore recommend not doing these things.
-
@bridget99 said:
I don't think you're using your debugger effectively. It's not just there for crashes. I personally write a lot of original code while stopped at a breakpoint.
I do that in java. Well, usually not a breakpoint I've set, but after the debugger has caught an unhandled exception. But that's not really all that different from what I'd do in C/C++, except that I can write code and hot deploy it right there with java.
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc. I'm not a fan of the context switch that's required to get to the part of the app where I'm working, then work, then try something, etc. Of course, that assumes that you're working on something that's interactive at all, which I'm often not.
-
@boomzilla said:
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc.
I'm going to go out on a limb and say that might have something to do with the debugger you're using.
-
@boomzilla said:
@bridget99 said:
I don't think you're using your debugger effectively. It's not just there for crashes. I personally write a lot of original code while stopped at a breakpoint.
I do that in java. Well, usually not a breakpoint I've set, but after the debugger has caught an unhandled exception. But that's not really all that different from what I'd do in C/C++, except that I can write code and hot deploy it right there with java.
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc. I'm not a fan of the context switch that's required to get to the part of the app where I'm working, then work, then try something, etc. Of course, that assumes that you're working on something that's interactive at all, which I'm often not.
It probably wouldn't be a new feature. If I know some expression in the code needs to be fixed or refactored, I'll sometimes set a breakpoint at the appropriate point, and when execution is stopped there, I'll then enter my reworked version of the expression directly into the code. This way, I get the benefit of watches, hover-over, the QuickWatch window, etc., shown with real data, while I'm entering my new expression. I mostly do this in .NET, but I seem to also recall doing a lot of similar things in the Visual Studio C++ debugger.
I did basically ignore such things for years, but eventually ran into some problems/timelines that forced me to use them. The same is true of Windbag; I used it once in (prolonged, extreme) anger, but only because I had to. To my credit, I documented all that project's little Windbag bugs for the benefit of the team.
-
(I documented the project's Windbag setup requirements... not "Windbag bugs.")
OT, but does anyone else think those Tsarnaev brothers might have been psychologically damaged by the Borat movie (even more than the rest of us)?
-
@morbiuswilters said:
@boomzilla said:
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc.
I'm going to go out on a limb and say that might have something to do with the debugger you're using.It has nothing to do with the debugger itself. Apparently I guessed incorrectly about what he meant, because his response sounded more like how I use a debugger.
-
@boomzilla said:
@morbiuswilters said:
@boomzilla said:
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc.
I'm going to go out on a limb and say that might have something to do with the debugger you're using.It has nothing to do with the debugger itself. Apparently I guessed incorrectly about what he meant, because his response sounded more like how I use a debugger.
How you can do that in command line debugger?
-
@bridget99 said:
@boomzilla said:
@morbiuswilters said:
@boomzilla said:
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc.
I'm going to go out on a limb and say that might have something to do with the debugger you're using.It has nothing to do with the debugger itself. Apparently I guessed incorrectly about what he meant, because his response sounded more like how I use a debugger.
How you can do that in command line debugger?Terminal window and editor windows must fly in close formation to do this, no?
-
@bridget99 said:
@bridget99 said:
@boomzilla said:
@morbiuswilters said:
@boomzilla said:
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc.
I'm going to go out on a limb and say that might have something to do with the debugger you're using.It has nothing to do with the debugger itself. Apparently I guessed incorrectly about what he meant, because his response sounded more like how I use a debugger.
How you can do that in command line debugger?Terminal window and editor windows must fly in close formation to do this, no?
Just to be clear:
Is your computer made of a goose?
-
@Ben L. said:
@bridget99 said:
@bridget99 said:
@boomzilla said:
@morbiuswilters said:
@boomzilla said:
But I get the feeling that you're talking about building up some new feature while you have the debugger going. To me, that's like writing some code, then answering the phone, writing more code, etc.
I'm going to go out on a limb and say that might have something to do with the debugger you're using.It has nothing to do with the debugger itself. Apparently I guessed incorrectly about what he meant, because his response sounded more like how I use a debugger.
How you can do that in command line debugger?Terminal window and editor windows must fly in close formation to do this, no?
Just to be clear:
Is your computer made of a goose?
No; Boomzilla said that GUI debuggers weren't any more productive than CLI debuggers. So, I was trying to imagine how to could accomplish some really advanced debugger tricks using a "flock" of terminal /editor windows.
-
@bridget99 said:
@boomzilla said:
Apparently I guessed incorrectly about what he meant, because his response sounded more like how I use a debugger.
How you can do that in command line debugger?I don't. If you were paying attention, you would have noticed that I said that I used both GUI and CLI debuggers.
-
@bridget99 said:
No; Boomzilla said that GUI debuggers weren't any more productive than CLI debuggers.
I didn't make such a categorical statement. Obviously, the ability to hot deploy code makes life nice. This is the main benefit I get from the integrated debugger in Eclipse when I'm debugging java. I don't have such a debugger available when I'm debugging C++, however, so the GUI debugger's main advantage to me isn't possible.
Since I learned to type as a kid, I'm not hobbled by the crutch of buttons, and a CLI debugger works just fine. I also don't have any mental handicaps when it comes to reading.
-
@boomzilla said:
Since I learned to type as a kid, I'm not hobbled by the crutch of buttons, and a CLI debugger works just fine. I also don't have any mental handicaps when it comes to reading.
Hmm.. I know how to use a CLI debugger just fine, and I use one a lot, but that doesn't mean I can't see how it is inferior to a GUI debugger in almost every respect (except maybe for the ability to script things..)
-
-
@dhromed said:
@boomzilla said:
I didn't make such a categorical statement.
Yes you did. :-*
Here are some examples of my statements on this:
@boomzilla said:
I use both CLI debuggers and IDE debuggers. Neither seems significantly more or less productive to me.I know that people like blakeyrat are convinced that a GUI is always and everywhere faster and more productive than any CLI, but that doesn't make it true.
I cannot see how that equates to:
@bridget99 said:No; Boomzilla said that GUI debuggers weren't any more productive than CLI debuggers.
I did clarify later that the hot deploy features of some debuggers are very useful, and when that's available and appropriate, I use it, so I suppose you could ding me on that in my initial statement. Of course, that isn't something inherent to GUI debuggers.
-
If you said that between CLI and IDE (GUI) debuggers, neither is more productive than the other, then it's kind of logically valid to say that you said that a GUI debugger isn't more productive than a CLI.
-
-
@dhromed said:
If you said that between CLI and IDE (GUI) debuggers, neither is more productive than the other, then it's kind of logically valid to say that you said that a GUI debugger isn't more productive than a CLI.
I said that neither is significantly more or less productive to me. I also followed up with an example of how some GUI debuggers are more productive when I can hot swap code. But that's not about the GUI-ness of the debugger, and I've used more GUI debuggers that don't do that than that do. It was also in reference to my personal use and preferences and capabilities. For instance, moving the mouse to hover over variables raises my blood pressure in a way that typing "print foo" does not. I can also set break points without having to click around to find a particular file and then scroll to the line where a method is. Some GUI debuggers have figured this out and support some of that through an immediate window.
So. I think that's a lot of caveats, which is kinda the opposite of a categorical statement.
-
@Ben L. said:
@blakeyrat said:
If software doesn't meet blakeyrat's subjective preferences, then it's objectively crap and its authors are either thoughtless or malicious.they release a really good IDE, a really good debugger, reflection tools, build tools, a new installer to work with it more cleanly, a new web server to support all its features, full 100% documentation coverage of the language and library, etc.
Your point being?
-
@boomzilla said:
For instance, moving the mouse to hover over variables raises my blood pressure in a way that typing "print foo" does not.
There's medication for that.
(me too, though, but that's because all debuggers I've used have these ridiculously tiny UI components and the whole thing always feels very volatile, like spinning plates.)
@boomzilla said:
So. I think that's a lot of caveats, which is kinda the opposite of a categorical statement.
Yes, but who cares? We're not doing science here. Why use fuzzy wording one minute and then switch to strictly defined terms for no apparent reason?
-
@dhromed said:
@boomzilla said:
So. I think that's a lot of caveats, which is kinda the opposite of a categorical statement.
Yes, but who cares? We're not doing science here. Why use fuzzy wording one minute and then switch to strictly defined terms for no apparent reason?My point exactly. Why did bridgett99 do that?
-
-
@boomzilla said:
@dhromed said:
If you said that between CLI and IDE (GUI) debuggers, neither is more productive than the other, then it's kind of logically valid to say that you said that a GUI debugger isn't more productive than a CLI.
I said that neither is significantly more or less productive to me. I also followed up with an example of how some GUI debuggers are more productive when I can hot swap code. But that's not about the GUI-ness of the debugger, and I've used more GUI debuggers that don't do that than that do. It was also in reference to my personal use and preferences and capabilities. For instance, moving the mouse to hover over variables raises my blood pressure in a way that typing "print foo" does not. I can also set break points without having to click around to find a particular file and then scroll to the line where a method is. Some GUI debuggers have figured this out and support some of that through an immediate window.
So. I think that's a lot of caveats, which is kinda the opposite of a categorical statement.
I actually use "Quick Watch," which is a sort of immediate mode code evaluation window, a lot more than hover-over. In general, I do think that making a real programmer aim at things with the mouse is pretty infantile. And it does raise my blood pressure when I have to do such things.
