Re: Feasibility of using Ada in new development
From: Stephen Leake (stephen_leake_at_acm.org)
Date: 09/04/04
- Next message: Wojtek Narczynski: "Re: Feasibility of using Ada in new development"
- Previous message: Jeff C r e e.m: "Embedded Systems Programming Magazine - Ada Mention"
- In reply to: Randy Brukardt: "Re: Feasibility of using Ada in new development"
- Next in thread: Georg Bauhaus: "Re: Feasibility of using Ada in new development"
- Reply: Georg Bauhaus: "Re: Feasibility of using Ada in new development"
- Reply: Pascal Obry: "Re: Feasibility of using Ada in new development"
- Reply: Jacob Sparre Andersen: "Re: Feasibility of using Ada in new development"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 04 Sep 2004 11:06:02 -0400 To: comp.lang.ada@ada-france.org
"Randy Brukardt" <randy@rrsoftware.com> writes:
> Actually, I have less tolerance for IDEs that try to 'help' by reorganizing
> my carefully structured program text. Or by changing identifiers to match
> some capitalization "standard", even if they don't make sense: "Text_Io",
> anyone?
Emacs solves the "Text_IO" case by allowing users to specify
exceptions to the default capitalization rule. I expect a "good IDE"
to do the same.
> In any case, my MS-DOS editor is multi-window, does auto-indenting,
> and allows all commands to be operated on blocks (even rectangles)
> of text. This last capability is invaluable, because it is often the
> case that you want to replace something is a section of text, not
> the whole file, and there often are enough mods that OKing each one
> isn't sane.
I don't use it much, but I believe Emacs can do this as well, although
not all commands will respect rectangles.
> As far as creating the program goes, any decent Ada compiler will do
> that with a single command (gnatmake for GNAT, make for Janus/Ada,
> and there are similar commands in IBM/Rational Ada and in
> ObjectAda). Nothing complicated about it, even if the program is
> split into shared libraries and the like.
The complicated part is fixing errors reported by the compiler. A
"good IDE" will capture the compiler output, parse it, and pull up the
source code with the cursor at the point of the and the error message
in another window. An "excellent IDE" will then, at a keystroke, fix
simple errors (like "= should be :="). Emacs (and GPS) does this.
This ability is a _large_ productivity gain. Ada reports lots of good
errors at compile time on "fresh" code; it must be easy to fix them.
It is also essential when refactoring; that also produces lots of
error messages.
> Let me assure you, if a GUI really would help me be more productive,
> I'd be using it. But short of building one myself (which I may do
> someday, the one we provide with Janus/Ada is garbage), I don't
> expect to see it.
I don't think of Emacs as a GUI, but it is and excellent IDE.
> > > all the GUI will do there is make it more likely to lose the
> > > settings (because they're in some obscure settings file in the
> > > registry or some remote directory, rather than in a batch file
> > > that gets backed up daily with the source code...)
> >
> > I would hope a high-quality IDE would not.
>
> An IDE is in a lose-lose situation here. If it clutters up the users space
> with all kinds of files with obscure contents, then people (rightly) will
> complain about the clutter. If it hides the files, they are likely to not
> get backed up. The "quality" of the IDE isn't going to fix this.
I have two project files for each Ada project; one for GNAT and one
for Emacs. The GNAT one sets compiler search paths and options; the
Emacs one sets error parsing search paths and capitalization rules.
Both are ASCII, human-editable. That's a very good compromise between
your two extremes.
> > > That said, I understand the many modern programmers are looking
> > > for GUIs to hold their hands, and certainly we support that.
> >
> > Maybe not hold my hand but at least help speed up tedious tasks.
>
> And that is my point. There are almost no tedious tasks in creating programs
> from the command line in Janus/Ada, or in GNAT. So a GUI simply doesn't buy
> much. The only thing I find tedious is waiting for the compiler to finish -
> and no GUI is going to help with that!
One tedious task is fixing compiler errors, as I discussed above.
Another is synching with a source code configuration management
repository. Emacs pcvs mode is hands down the best user interface for
this I have ever seen. It presents a list of files that need
attention, and offers advice on what to do with each. Rational
ClearCase doesn't come close to that; neither does GPS or any other
CVS GUI. This is an absolute requirement for IDE's used by my team;
consequently, they are all using Emacs (and I'm not getting complaints
after the first month :).
> ... > > Of course, that's just part of a general dumping-down of
> programming. And > > that's what managers want: they want any idiot
> to be able to build software, > > so they can hire minimum wage
> people (or outsource) to do the job. But > > you're never going to
> get anything well-designed and maintainable that way.
> >
> > I assume you made a typo above and mean dumbing-down?
>
> Yes, it was a typo.
I agree here. Emacs is a powerful tool, and takes time to learn and
skill to use well. One guideline in judging a potential team member is
to ask if they like Emacs. If they've never tried it, I give them a
chance. If they have tried it and don't like it, they are suspect.
Same for whether they like Ada.
-- -- Stephe
- Next message: Wojtek Narczynski: "Re: Feasibility of using Ada in new development"
- Previous message: Jeff C r e e.m: "Embedded Systems Programming Magazine - Ada Mention"
- In reply to: Randy Brukardt: "Re: Feasibility of using Ada in new development"
- Next in thread: Georg Bauhaus: "Re: Feasibility of using Ada in new development"
- Reply: Georg Bauhaus: "Re: Feasibility of using Ada in new development"
- Reply: Pascal Obry: "Re: Feasibility of using Ada in new development"
- Reply: Jacob Sparre Andersen: "Re: Feasibility of using Ada in new development"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|