Real-World IDE for Web Dev?

httpete

Sparks wrote: »

What changed in our workloads that the extra second it takes to alt-tab (actually altGr-<number> but I use awesome so I'm a bit of an outlier) between your debugger and your editor has added too much overhead to allow you to be productive?

There's more to it than just alt-tabbing, which itself is bad enough. Imagine if every time you wanted to change the font size or scroll to another part of a document in Word you had to alt tab to another application to do it. It would be considered unacceptable and Word have disappeared long ago. Or if you were using Photoshop and you had to alt-tab into another program whenever you wanted to make a selection and manipulate it.

You have to open a separate program to debug an application, then you trace the code execution across multiple files and find out what sections are causing the bugs - Then you have to go back to your DE and open those same files and scroll to the same parts of those files to make your changes. You'll probably have to tab back and forward multiple times between the two programs to locate what sections/need to be changed. Why put up with that in 2013 when it can all be done in the one IDE?

Sparks

httpete wrote: »

There's more to it than just alt-tabbing, which itself is bad enough. Imagine if every time you wanted to change the font size or scroll to another part of a document in Word you had to alt tab to another application to do it. It would be considered unacceptable and Word have disappeared long ago. Or if you were using Photoshop and you had to alt-tab into another program whenever you wanted to make a selection and manipulate it.

That argument is assuming as an axiom that the editor and the debugger are the same application; but that's not an axiom, it's the thing we're trying to discuss. You need to step back a wee bit and reexamine the argument again.

You have to open a separate program to debug an application, then you trace the code execution across multiple files and find out what sections are causing the bugs

Er, what? You don't trace code execution across multiple files, you run to the point in the executable where things break, then you examine the stack and the contents of memory in the core dump at that point (or you just run in the debugger and grab it directly), and if you need to see something that happened before that point, you set a breakpoint and run to that instead.

If you're actually single-stepping through an entire program to find a bug, then either its a really, really small program; or it's a situation you're not describing well enough and I've read you wrong; or worst of all, you've not used a debugger enough.

Then you have to go back to your DE

- just a quick point, I said "DE" to mean "Development Environment" because we were talking about IDEs and non-IDEs and really, a non-IDE is just a DE -

and open those same files and scroll to the same parts of those files to make your changes.

Okay, first off, you only need to open the one file; the one with the line of code you've stopped at. In any editor you know how to use, that's a fast operation, and odds are you already have it open anyway. And secondly, you don't scroll, you jump to line. And if you can't do that, you really really need a better editor, all fun bull**** about vi-v-emacs aside because there are certain things a programmers editor *has* to do and quickly navigating around a file is one of the first of those things.

You'll probably have to tab back and forward multiple times between the two programs to locate what sections/need to be changed. Why put up with that in 2013 when it can all be done in the one IDE?

Okay, take it from someone who's been doing this since 1993 in programs ranging from the tiny exercises we give you in college to the 30 MLOC behemoth I'm working in now; what you've described, you've described badly because it doesn't work like that; and it's enormously faster for me to do this using gdb or totalview and vim than it would be to try it in eclipse or another IDE. Hell, there aren't even that many IDEs that can even work at the 30MLOC level, and none I've seen that work fast.

Besides which, most of the things you use the IDE for I already have in vim and have had for a long time. With smaller projects, you can tie the editor more closely to the code with things like integrated debugging, clang syntax checking, code completion and so on. Take a look: http://val.markovic.io/blog/youcompleteme-a-fast-as-you-type-fuzzy-search-code-completion-engine-for-vim

But frankly, I don't even bother with those most days in here because the codebase is just too large and all the behind-the-scenes searching that goes on for some of those features really chugs with 30MLOC to deal with. Ctags can keep up, and cscope just about holds its own (cscope and C++ are uneasy bedfellows, but not utterly incompatible); but code completion is just a drag.

And trying to integrate a debugger just makes complex test cases harder. I can do a lot more with a seperate debugger, just because of the structure of the programs (it's an enormous multithreaded cross-platform application - not many IDE debuggers are up to the task; hell, not many debuggers can cope with it full stop. We even have to be careful what symbol format we compile with because of the limits of the debuggers. If it's not DWARF-2, things go splat unless you're using gdb).

Honestly, speaking from direct first-hand experience, IDEs just can't cut it with some applications.

oeb

When it all comes down to it, this is a bit of an odd argument.

Programmers will generally excel at using the tools they use on a day to day basis, there is more of a learning curve to developing without an IDE, but when you have been doing it day to day for years it becomes second nature. You know the commands off by heart, you don't need to look up command line arguments for running your tools (well, except tar), you are used to doing it this way.

Don't get me wrong, an IDE is much more accessible for (especially) newer developers, there is less of a learning curve, you don't need to teach someone multiple different tools, because it's all rolled in to one.

As to which is more effective? I would be extremely supprised if there was any real difference (productivity wise) between two equally skilled developers with similar experience if one had spent the last 5 years working with VIM and seperate tools like gdb and the other had put in the same time with something like visual studio.

Different strokes and all that.

httpete

Sparks wrote: »

Er, what? You don't trace code execution across multiple files, you run to the point in the executable where things break, then you examine the stack and the contents of memory in the core dump at that point (or you just run in the debugger and grab it directly), and if you need to see something that happened before that point, you set a breakpoint and run to that instead.

If you're actually single-stepping through an entire program to find a bug, then either its a really, really small program; or it's a situation you're not describing well enough and I've read you wrong; or worst of all, you've not used a debugger enough.

Of course I'm not single stepping through an entire program. But if there is a bug in some component of a system it may not be immediately apparent the exact pinpoint location of the bug, and the problem might actually be composed of multiple bugs in different places. I don't know what language you are developing in (I presume C or C++) but if I'm working with Java or PHP I may have the component in question split across many files. So when I'm debugging with the integrated debugger it automatically opens each file as the execution enters those files. I'll step through an area in question to see exactly what is happening with breakpoints set at questionable areas. An integrated debugger gets rid of the need to have the same files open in two separate programs.

Okay, first off, you only need to open the one file; the one with the line of code you've stopped at. In any editor you know how to use, that's a fast operation, and odds are you already have it open anyway. And secondly, you don't scroll, you jump to line. And if you can't do that, you really really need a better editor, all fun bull**** about vi-v-emacs aside because there are certain things a programmers editor *has* to do and quickly navigating around a file is one of the first of those things.

Jump to line, scroll to line or even click on line in sidebar with ST2, whatever...its still an extra step in having to navigate to that line to make a change in the original file when an integrated debugger will automatically put you at that line as the program executes.

Okay, take it from someone who's been doing this since 1993 in programs ranging from the tiny exercises we give you in college to the 30 MLOC behemoth I'm working in now; what you've described, you've described badly because it doesn't work like that; and it's enormously faster for me to do this using gdb or totalview and vim than it would be to try it in eclipse or another IDE. Hell, there aren't even that many IDEs that can even work at the 30MLOC level, and none I've seen that work fast.

gdb is a pain in the hole compared to debugging in something like Visual Studio where the registers, stack and memory are visible at all times on the screen and you don't have to type anything to see them.

Honestly, speaking from direct first-hand experience, IDEs just can't cut it with some applications.

Some applications, some being the operative word. Most applications that people work on are not 30MLOC. The majority of applications are capable of being handled in an IDE.

Sparks

httpete wrote: »

Of course I'm not single stepping through an entire program. But if there is a bug in some component of a system it may not be immediately apparent the exact pinpoint location of the bug, and the problem might actually be composed of multiple bugs in different places.

Yes, that's true of many different programs, including the stuff I'm working on (where the problem might be split across different machines as well).

But by the time you get to that stage, I don't think even integration will help - it's just going to be a bitch of a problem to find anyway.

So when I'm debugging with the integrated debugger it automatically opens each file as the execution enters those files.

But my debugger will happily tell me which file the code it's executing originates in - as will any debugger from the first debugger onwards really - and that's all the information you need.

I mean, if it was a speed typing competition, maybe, but you're trying to grok the problem to fix it - what you need is the data and time to think, raw editing time doesn't come into it (and really, you'd only be saving a matter of one to three seconds anyway, depending on how practiced you are). You'd be optimising the wrong thing in your workflow.

I'll step through an area in question to see exactly what is happening with breakpoints set at questionable areas. An integrated debugger gets rid of the need to have the same files open in two separate programs.

But I don't need to open the files by hand in the debugger, it does that as a matter of basic functionality. So all I'd need to do is open the file when and where I'm making a change. That's an incredibly minor operation.

gdb is a pain in the hole compared to debugging in something like Visual Studio where the registers, stack and memory are visible at all times on the screen and you don't have to type anything to see them.

Yup.
However, gdb excels in other areas that VS doesn't - it's one of the few debuggers I can run remotely over a slow network link without having time to learn to juggle between keypresses
(and that's without mentioning the cross-platform stuff or any of the other things I've liked about gdb over the years; and I'm not a gdb expert...)

Besides, when I need the stuff you're talking about, I just use something like totalview or ddd (which is just a front-end to gdb, because gdb can get all that info you want, it just has a 1970s UI).

Some applications, some being the operative word. Most applications that people work on are not 30MLOC. The majority of applications are capable of being handled in an IDE.

Yup.
Of course, you're screwed if you wind up needing that skill and not having it...

Besides, 30MLOC is definitely up at the high end, but even at one or two orders of magnitude less code, you still cause a lot of tools to chug (ever seen eclipse's appetite for memory? Yikes....). The fact that I need less hardware to do the same job isn't an insignificant fact really.

Trojan

Are we still talking about "Real-World IDE for Web Dev"?

I think you might be a bit of an edge-case there, Sparks

Colonel Panic

PHP debugger is still an oxymoron, right?

Sparks

Trojan wrote: »

Are we still talking about "Real-World IDE for Web Dev"?
I think you might be a bit of an edge-case there, Sparks

True, that

ChRoMe

Colonel Panic wrote: »

PHP debugger developer is still an oxymoron, right?

Fixed your post

KonFusion

ChRoMe wrote: »

Fixed your post

Why are PHP devs morons?

ChRoMe

KonFusion wrote: »

Why are PHP devs morons?

Well the ones that choose (rather than are forced) to use a language, that is literally just broken. I'm not talking about "oh it encourages sloppy code", its actually just ****ing broken and not fit for purpose. If you are interested to go into the details this post has a long (although not exhaustive break down of issues).

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Colonel Panic

I'm not a fan of PHP as a language but it doesn't make people who use it by choice morons. If only everyone could open their editor (Emacs) and just know the best language to use and the right way to do everything right away.

ChRoMe

Colonel Panic wrote: »

I'm not a fan of PHP as a language but it doesn't make people who use it by choice morons. If only everyone could open their editor (Emacs) and just know the best language to use and the right way to do everything right away.

Well perhaps its unfair to call them morons. However its certainly correct to accuse them of being poor developers.

Sparks

I think perhaps we just tripped and stumbled across the line there from late-night joshing in a pub standards meetup to late-night breaking of beer bottles over someone's head, and since I hate to see perfectly good beer wasted, maybe we could dial it in a notch or two?

I mean, if we were busy dissing emacs I wouldn't say much, but PHP's not really worth the argument

Colonel Panic

ChRoMe wrote: »

Well perhaps its unfair to call them morons. However its certainly correct to accuse them of being poor developers.

Why are they poor developers? I just don't get it.

IRLConor

I don't understand language chauvinism any more.

If you don't realise that the language you're using is deeply flawed and broken in some way then you haven't used it enough. If you think language A is better than language B then you're almost certainly wrong.

Procasinator

ChRoMe wrote: »

Well perhaps its unfair to call them morons. However its certainly correct to accuse them of being poor developers.

One good reason to use PHP is business reasons.

Some examples:

1. Plenty of hosts, in all price brackets.
2. Plenty of developers available.
3. Plenty of ready-made, off the shelf components to use.

I believe WordPress, vBulletin, e.t.c. can partly thank their success to PHP, particularly benefiting from 1 & 2. Sometimes you use a language not because of the language itself, but the environment around it (tooling, available workforce, hosting, easy entry, e.t.c)

I'm sure Facebook has a load of PHP developers who are far from poor developers.

ChRoMe

Procasinator wrote: »

I'm sure Facebook has a load of PHP developers who are far from poor developers.

The wonderful thing about that statement is that, they dont have any PHP developers. They realised it was so bad, that they completely rewrote the runtime from the ground up.

Also, of course all languages have issues, no doubt about it. However not all issues are equal.

</rant>

Trojan

ChRoMe wrote: »

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

I love that guys toolbox analogy.

Procasinator

ChRoMe wrote: »

The wonderful thing about that statement is that, they dont have any PHP developers. They realised it was so bad, that they completely rewrote the runtime from the ground up.

Also, of course all languages have issues, no doubt about it. However not all issues are equal.

</rant>

Of course they have PHP developers, they just have their own VM (and for a while, cross compiler). That like saying if I use a different Java VM other than Oracle's, PyPy instead of CPython, JRuby instead of Ruby, Mono instead of .NET, e.t.c. that I'm not a developer in any of those languages.

ChRoMe

Procasinator wrote: »

Of course they have PHP developers, they just have their own VM (and for a while, cross compiler). That like saying if I use a different Java VM other than Oracle's, PyPy instead of CPython, JRuby instead of Ruby, Mono instead of .NET, e.t.c. that I'm not a developer in any of those languages.

Its more of a distinct difference, the syntax remained, everything else was dumped more or less.

ChRoMe

Trojan wrote: »

I love that guys toolbox analogy.

The whole thing hits the nail on the head (sorry!)

Colonel Panic

Except all it says is that the language is inconsistent, full of leaky abstractions and cruft. Not that anyone who uses it is a poor developer.

ChRoMe

Colonel Panic wrote: »

Why are they poor developers? I just don't get it.

I wouldnt put much faith in a brick layer that used blu tack. Choosing appropiate tools for the job is half the battle.

Colonel Panic

Sure, there's that but we live in the real world, not an ivory tower wallpapered with pages from Knuth and GoF.

ChRoMe

Colonel Panic wrote: »

Sure, there's that but we live in the real world, not an ivory tower wallpapered with pages from Knuth and GoF.

So why even bother trying, lets all settle for the worst there is, because nothing is perfect right?

What a terrible attitude. You should at least pretend to give a **** about the quality of your work.

Procasinator

ChRoMe wrote: »

Its more of a distinct difference, the syntax remained, everything else was dumped more or less.

The language itself remains, the grammar hasn't changed. Let's not confuse the language with the implementation. While they are of course often interlinked, the link to the implementation is becoming more and more blurred these days.

They haven't ported over all the extensions of course, but they have done a decent chunk and a lot of common PHP applications can run under HipHop.

Sparks

Mod hat on.

*ahem*
Chillax, dudes. Or whatever it is you young folk say these days. This argument started when someone thought Fortran was better than COBOL and it's not going to end anytime soon, so gouging eyes and breaking fingers over it would be a waste of effort, m'kay?

Procasinator

ChRoMe wrote: »

So why even bother trying, lets all settle for the worst there is, because nothing is perfect right?

What a terrible attitude. You should at least pretend to give a **** about the quality of your work.

Are you saying you can't produce quality websites with PHP? I don't really like PHP, but we've seen many successful packages and even businesses running under PHP. I'm not saying there code is the finest you'll see, but it can run it under the scale of Wikipedia, Facebook and Boards.ie :P, it's not all that bad.

You can produce crap in any language. Quality tools undoubtedly help produce quality solutions, but the practitioner who is using them is the important part.

Colonel Panic

ChRoMe wrote: »

So why even bother trying, lets all settle for the worst there is, because nothing is perfect right?

What a terrible attitude. You should at least pretend to give a **** about the quality of your work.

Well that's not really what I'm saying at all.

I take great pride in my work, which is never written in PHP, but I certainly don't think anyone is a bad programmer or a moron for choosing a sub-optimal language or framework!

It's much more pleasant to poke fun at the language, editor, framework without dragging people into the equation. Sometimes the right tool for the job is the quickest, cheapest more widely available one.