Integrated Development Environments ... can't live with 'em ... can't shoot 'em ... can't live without 'em.
timhahn 100000F0AC Visits (3311)
Ah, the wonders of software development in the twenty-first century!
It seems as though software development these days is going through something of a "retro" period. People are seemingly eschewing their love of the Integrated Development Environment (IDE) in favor of bare-knuckle command-line tools the likes of which have funny names ... cf, grunt, ant, and so on. Why is this the case? What happened on the way to the wonderful world of graphical application development and programming with pictures?
Well, I for one have become more and more dependent on my IDE when I'm doing heads-down programming. When I need to be working with a gazillion source files at once, navigating around them, making fixes to a bunch of them at the same time, finding definitions, getting assistance in completing some syntactical conundrum, or whatever, I find the IDE environment pretty much indespensible. Add to that the idea that I can drop into a debugger at will, step through my code, find the brain-dead mistake I made and the jump right back to the source and fix it - how can I live with out it?
Second, I see that people are getting really comfortable working with environments where the system on which their code is running is no longer even remotely associated with the system they are using to writ
Well, I'm happy to report that here at IBM, we already had this covered years ago. We had a whole set of server-side systems that were "graphically challenged". What did we do? We created really great programming environments that hid all the ugly details of doing all that deployment gorp, moving files between systems, doing remote compiles, and links, and deploys. Those tools interacted (and still do!) with remote AIX, Linux, IBM i, and System z (Linux on System z and z/OS) systems. Those tools interacted (and still do!) with application server environments (WebSphere and Apache) running on those remote systems. And those tools even enabled interactive debug of applications running in those remote systems ... all with a graphical user interface, hosted and running on the user's workstation. By now I'm sure you know what I'm talking about. The Rational development tools like Rati
One thing that has always been frustrating though is how to learn to use an IDE. They're supposed to be self-documenting - it's a graphical user interface after all - how hard could it be? Well, pack enough features into a tool and users quickly lose the trees in the forest. Like a tool-box that's over-stuffed, the tool you want/need is always buried at the bottom, hidden by a bunch of things you have no interest in.
But I'm happy to say that there's hope for us all, even with all of head-winds above. There are people and teams that do know how to use the IDEs and are ready and willing to spread that knowledge to everyone who is willing to listen. Some of that learning is even at the "right price" ... FREE. So, if you want to learn about remote application development, for applications running on z/OS, check out the the link for RDz
And everyone else - just remember that there are great ways to get the best of both worlds - build applications for a wide range of deployment models and platforms, and get the great features of using an Integrated Development Environment. All you have to do is use those IDEs that are already enabled for what I call "remote development".